WIP: Feature/#415 use resource pointer directly as component

We use ResourcePointers directly instead of through HandleComponents which only wrap the resource pointer.

Please take a close look. I needed to declare the copy constructor and operator of Component from delete to default. That should in general be no problem, since we store the components within the entities in unique_ptr what makes them non-copyable.

added 1 commit

• 7118faec - Removed type traits for resource pointer.

Compare with previous version

By Ali Can Demiralp on 2018-05-25T14:05:37 (imported from GitLab)

changed title from Feature/#415 resource pointer c cmponent to Feature/#415 use resource pointer directly as component

By Jonathan Ehret on 2018-05-25T15:05:29 (imported from GitLab)

changed the description

By Jonathan Ehret on 2018-05-25T15:05:29 (imported from GitLab)

mentioned in merge request !130 (merged)

By Jonathan Ehret on 2018-05-28T08:32:16 (imported from GitLab)

In !130 (merged) MeshHandles get a property wireframe, to render them as wireframes.

Copy of that discussion, since it belongs here:

Since we removed these handles in !129 (closed) maybe add a renderable component? Something were also the decision between different shaders etc. would go?

So add a RenderComponent?

By Jonathan Ehret on 2018-05-28T15:32:15 (imported from GitLab)

resolved all discussions

By Jonathan Ehret on 2018-06-12T11:25:31 (imported from GitLab)

Blocked by #445 in !133 (merged)

By Jonathan Ehret on 2018-06-13T07:20:43 (imported from GitLab)

To me, this change does not feel right as it is now. The problem is, that now we can have Components without an Entity. The ResourcePointer is meant to be moved around a lot, while the Component is meant to be assigned to a certain entity. These are very different concepts that cannot be easily unified in one class.

We might do a compromise and have a new ResourceComponent class that is a Component but holds a Resource pointer. We might also think about weakening the relationship between Component and Entity.

By Martin Bellgardt on 2018-06-19T10:41:41 (imported from GitLab)

Yes I think I am with @mbellgardt here, having a ResourceComponent would probably be a good compromise, although I am not sure what it should be called, we never added Component to the name of the components, so maybe ResourceHandle although this sounds very artificial to me as well...

By Jonathan Ehret on 2018-06-19T10:55:03 (imported from GitLab)

I would have to concur with both of you. This looks odd in code.

By Bernd Hentschel on 2018-06-25T07:56:40 (imported from GitLab)

although this sounds very artificial to me as well

I LIKE WHAT YOU GOT

By Ali Can Demiralp on 2018-06-25T20:06:27 (imported from GitLab)

Thats because the abstraction is artificial.

By Ali Can Demiralp on 2018-06-25T20:06:49 (imported from GitLab)

Onion peeling like

entity->get_component<resource_handle>()->get_resource()->as<mesh>()

is bad just inherit the resource base class from component or something along those lines instead.

By Ali Can Demiralp on 2018-06-25T20:13:11 (imported from GitLab)

marked as a Work In Progress

By Jonathan Ehret on 2018-06-26T11:56:30 (imported from GitLab)

resolved all discussions

By Jonathan Ehret on 2018-06-26T11:56:34 (imported from GitLab)

Ok, so maybe we should dicuss that in the planning meeting, so blocked by #415

By Jonathan Ehret on 2018-06-26T11:57:03 (imported from GitLab)

closed

By Jonathan Ehret on 2018-07-24T09:05:22 (imported from GitLab)

mentioned in merge request !160 (merged)

By Jonathan Ehret on 2018-07-24T09:21:37 (imported from GitLab)

Now in !160 (merged)

By Jonathan Ehret on 2018-07-24T09:22:01 (imported from GitLab)