Request: Entities Without models

[TylerH]

I am a bit annoyed by the fact the things like lights, emitters, and other "info" type entities need to have a gmf model and phy file. This is a waste of objects the scenegraph has to go through, and they aren't even removed when loaded in a game, causing issues with anything from doing line picks, to causing slow downs.

 

I would like to formally request the ability to have entities that don't have to have a model with them. A light should be able to just be a light entity, an emitter be an emitter. If you want to attach an entity to a mesh, go right ahead, but it shouldn't be required...

 

This is a major problem, and it should be dealt with timely.

[Gardowyr]

I completely agree with Tyler. The current way of dealing with those info objects causes a massive overhead and should be replaced with something more streamlined such as a way of just placing an info xml/ini/whatever file in a folder instead of having phy spheres and invisible objects everywhere. Just think of AI nodes or emitters, there might be an enormous number of those in a finished scene.

[Canardia]

I agree that it should be possible to remove the physics balls caused by lights, emitters and other entities which really don't need a physics body with LUA.

 

At the moment the only way to remove the physics balls is to use GameLib's processscene, which just recreates the entity and deletes the original entity which was created by LoadScene(). However, that will also remove the LUA script of the entity from memory, and I don't know if it can be reloaded.

[TylerH]

Exactly. This is why something needs to be changed about how the system fundamentally works.

 

The hierarchy is TEntity, from which TMesh inherits, and TLight inherits TEntity too. It doesn't go TEntity, TMesh, TLight inheriting TMesh.

 

You should be able to have entities in the editor that are just that, entities. If you want meshes, you parent a mesh, or do whatever.

[Rick]

To me it seems the only reason it has a gmf is so you can move it in scene via the editor/Sandbox.

[Josh]

The reason these entities are linked to a model is because a model has a script, and can be moved around and deleted again. This allows you to make lights, particle emitters, or anything else in script, and the editor doesn't have to have everything hard-coded.

 

If you want to get rid of the model component in your own game loading routine, you can just modify the script to remove the model when your game loads the scene. Something like this:

 

if MyGameIsRunning==1 then

object.light:SetParent(nil,1)

object.light=nil

object.model:Free()

end

[TylerH]

But why must we be forced to have models? Why can't we have entities that are in fact modeless? Take a look at any other editor out there, and you will see that none of their info, light, etc. type entities have a model and physics shape...

[TylerH]

To me it seems the only reason it has a gmf is so you can move it in scene via the editor/Sandbox.

 

But why? It isn't like emitters and lights and such don't have Position, Rotation, and Scale on their own...

[Rick]

But why? It isn't like emitters and lights and such don't have Position, Rotation, and Scale on their own...

 

 

My guess is because it's easier if they have models. The editor can just do a mouse pick against a model to select it. Sure lights and such have position, rotation, & scale, but if they don't have a model how would you select them with your mouse in the editor? It obviously could be done, but it would most likely require something outside of the LE commands and something more about the editor program. Currently it's really easy to allow mouse selecting since there is a model associated with it a simple mouse picking works.

 

So think about how would you go about allowing mouse selecting of something inside LE that didn't have a 3D mesh.

 

 

I don't care if these entities have models in them during development of the scene, but when the game runs all these entities should have a setting that the framewerk uses to determine if it should remove the mesh or not. I feel like the scripts should be tied to entities and not models. That would take that restriction away, but then you still have the mouse positioning issue to fix.

[Rick]

The reason these entities are linked to a model is because a model has a script, and can be moved around and deleted again. This allows you to make lights, particle emitters, or anything else in script, and the editor doesn't have to have everything hard-coded.

 

If you want to get rid of the model component in your own game loading routine, you can just modify the script to remove the model when your game loads the scene. Something like this:

 

if MyGameIsRunning==1 then

object.light:SetParent(nil,1)

object.light=nil

object.model:Free()

end

 

Wouldn't you run into a problem of the script not being called then if you do that? A good example would be my 3rd person camera object. I don't need a model for it, but I must have a script being called because there is code in the Update() function that gives functionality.

[TylerH]

Most editors I see test against the AABB of the entity, and select based on that.

 

I can come to some middle ground, and would settle for meshes, if we could atleast not have the auto-generated phy files.

 

EDIT: Maybe not. Meshes are what get detected in the pick commands, so we would still have that problem.

 

Removing them ourselves just seems hacky. There should be something like this in by default.

[Josh]

But why must we be forced to have models? Why can't we have entities that are in fact modeless?

Because in LE a model is the only scripted entity, so a model and a script allow you to create any kind of object you want. Particle emitters, lights, roads, etc., can all be implemented using this convention. If you want to get rid of the extra model when your game loads it, this is pretty simple to do. It shouldn't make any difference though, since the model is invisible and normally will have no collision set. If you want to make the model so it isn't even pickable, replace it with a GMF file that has no surfaces...then you would only be able to select the object by clicking on its node in the objects tree in the side panel.

[TylerH]

I can settle for that solution. Thanks.

[Josh]

Most editors I see test against the AABB of the entity, and select based on that.

If you want an AABB you can also make a mesh that represents that shape.

 

If we had a model-less entity you drag into the scene, it creates some design problems. Let's say the entity is an emitter. Where does the class script come from? Does script support have to be added to the base entity class, instead of just the model? If so, how does the script delete whatever entity it starts with, and replace it with an emitter, using the same script? What if the emitter is deleted and recreated, as happens when the particle count changes?

[TylerH]

I like the way OGRE does it.

 

A Scene manager, you have scene nodes, and you attach entities, lights, billboards, emitters, etc. to the nodes.