Hidden entities still get iterated over in LE?

[darthlukan]

I don't think it's a question of usefulness at all, it is. The performance gains alone would be enough. The only issue I see is that, depending on how entities are "sent" to the physics system, it could be really complicated to get right for 100% of cases.

 

As Leadwerks gains more popularity and people want to build more complex games, the physics system's efficiency and level of control becomes even more important. It's the kind of feature that brings parity to Leadwerks as compared to other engines that have a way of doing the same thing.

[Josh]

There's always a tradeoff. If hiding an entity deletes the physics body then quickly hiding and showing entities will introduce a new performance penalty, as the physics body has to be re-created each frame.

 

In fact I just checked the source code, and if the entity has mass=0, no shape set (or set the shape to NULL), and if not connected to any joints, the physics body is removed.

[Rick]

I think the question really is, can a physics body exist but not be looped over. Much like how you keep entities existing if hidden they just aren't looped over, the physics engine should have the same functionality so it does not incur this creation/removal penalty with hiding/showing.

 

I mean this would make sense wouldn't it? If the entity is hidden the physics body should not be considered in any calculations either. The memory of these rigid bodies is seemingly not the issue here. Memory isn't what's killing the FPS, it's the physics engine looping over these rigid bodies when it doesn't need to.

[Josh]

It's not really being "looped through" it's causing a box intersection test to run a callback that asks the engine if the collision is allowed to occur. Since the entity is hidden, then engine returns 0 and the collision is ignored. Having 10,000 objects positioned at the origin will result in a lot of wasted calls. If they were simply placed in the distance away from any active object, or deactivated in the manner I described, that would go away.

[Rick]

or deactivated in the manner I described, that would go away.

 

But this incurs the run-time cost of creation/deletion of the physics body which is not good and can kill FPS too.

 

So can we nix the callback from being ran if the entity itself is hidden so it doesn't make a call that's not needed? I'm assuming the newton library is calling an LE function for each intersected body. No way to tap into a pre-check before this function call? Is that callback call really the slowdown? How is Newton deciding on what body to make the callback on? I would assume internally there is a list? Are you assigning the callback to each body? Maybe if an entity is hidden you can remove the callback for that specific entity and then add it back when shown. This shouldn't incur any performance hit if this is the way it works.

 

 

If they were simply placed in the distance away from any active object

 

So my bigger example wasn't all at the origin, but the trees were touching the ground (and they are spread all over the place not stack on top of each other) which has collision. So you are saying if they trees were not intersecting with the ground (maybe 1 smallest unit above the ground body) the performance should be the same as if it were just the model itself?

 

 

[EDIT]

From my tests when the trees intersect with the ground it starts at about 6 FPS and just gets worse and worse. So yes, this is probably the callback issue. However, when I raise the trees from the ground (and they interest with nothing) I get a consistent 6 FPS if they are all shown and 15 FPS if they ALL are hidden. It doesn't get worse, so I see the effect of what you are saying but Newton must still be iterating over all these bodies itself even if they aren't intersecting with anything. They have to be iterating over an internal list to see if they should be calling the LE function callback right? That iteration is what has to be killing performance.

[Josh]

If you don't want collision on an object, why not just remove the physics shape file and it won't ever be created?

[Rick]

We would want collision on it, but these things may be far far away from the player or not accessible at a given time and have no reason to check collision on it until the player is coming up on it.

 

Think of Vectronic having 30 "areas" in 1 map because he doesn't want loading times to load another map or prefab. A lot of the models may be reused so the one map loads fast because it's mostly loading instances. 1 area is used at a time but all 30 need physics and creating these at the time of need (run-time) will cause a noticeable slowdown. However all 30 are causing a FPS hit when they shouldn't. Instead, he can hide all the rest (and if the physics wasn't taking up cycles when entities where hidden) and he would get great FPS. Via triggers he can show/hide the next/previous area. Now he can get very detailed with his areas physics wise and not affect the overall FPS. Today, he can't do that.

 

This idea extends to a lot of different games. This let's us control a level of optimization of these things via showing and hiding entities as our games see fit (and from a logical perspective when an entity is hidden it just makes sense it shouldn't have to care about physics).

 

 

When I remove physics from the tree and I have 146,691 trees/grass in my scene I get a solid 60FPS. However, things are so dense that I don't need all those trees to be visible. I could cut that number by a lot by hiding trees outside a certain range and it would look the same to my player and would save on the physics calcs if it worked this way.

 

On the other side, in a situation like trees, and I think you do this in your veg system, physics is only needed around moving objects. That physics body on a tree 30 steps in front of me isn't needed until I get close to it. An option like this for us to control would be even better! We don't even need the veg system if we had this on the entity level. It seems it's really the physics that is killing almost all performance with this stuff. Bodies on things that don't need it yet. I mean I could make a system that creates 10 bodies for these trees and I just dynamically attach/detatch them to trees that are just around the player/actors as they move around and I would get the same great performance I'm seeing of having no bodies on anything but have the added benefit of getting collision.

[Josh]

Again, why this extreme volume of objects? When you have hundreds of thousands of objects the parameters change, and that is what the vegetation system is designed to handle. The only thing in a game that will call for that huge of a number of objects is vegetation. Even if you have hundreds of buildings, the performance penalty of having those objects won't be much.

[darthlukan]

Because the whole point is to cache the item (since you will use it, just not "right now", maybe on a trigger) at load time and then incur a lesser performance penalty by simply "showing" it when you do need it. It's faster to have an entity present (but not having its physics calculated) and then show it when ready than it is to have a trigger that then creates the entity, which incurs the heftier penalty.

 

Sure, you can remove a shape file so that the item doesn't get loaded, but then what are you supposed to do once you need physics applied? Create the file and then force a reload on however many copies of that entity?

[Josh]

This doesn't make sense. You want to make the engine more complicated and introduce new bugs because of an extreme outlier situation? This would normally give you perhaps a 0-2% improvement in speed and make everything much more complex to use.

 

Leadwerks will never handle more than a few thousand individual entities in a scene very well. It's not designed to.

 

Beyond that, visibility has nothing to do with physics. If the developer has to worry about which offscreen physics occur and which don't, they are going to be very confused when a door doesn't open when it's supposed to, or some other reaction occurs. When objects are at rest, the physics system is very efficient. It will never accomodate tends of thousands of objects. That's what the vegetation system does.

 

I notice that any time we come out with new models or gameplay additions, people always start wanting to reinvent the engine. It's a pattern that happens every time. It's like clockwork, new model pack DLC = requests to switch to lightmaps or make other fundamental changes.

[Rick]

This would normally give you perhaps a 0-2% improvement in speed and make everything much more complex to use.

 

I don't agree with that. The performance gain's look very large to me.

 

 

Leadwerks will never handle more than a few thousand individual entities in a scene very well. It's not designed to.

 

The idea we are exploring here is that it can be designed to. The thing holding it back is hidden objects still calculating physics when it's not needed. It's a waste of cycles and only gets worse as maps get more populated.

 

 

It will never accomodate tends of thousands of objects.

 

This is what we're trying to find out. Is it because there is no way to do it or because you don't want to entertain the idea? We don't know the details of how LE is handling this.

 

 

That's what the vegetation system does.

The veg system, while nice, is still limited in that those are not real entities and cannot be treated as real entities. The recent trend of survival games almost always allows people to cut trees down for resources. This system doesn't allow that.

 

I notice that any time we come out with new models or gameplay additions, people always start wanting to reinvent the engine. It's a pattern that happens every time.

 

It's because the systems always have a drawback. This is why every time you make a new system my first question is, "What is the draw back". These being "fake" entities is the draw back.

 

 

It's OK to acknowledge limitations of systems. Everything has limitations and there is nothing wrong with exploring ideas around them. It doesn't mean you have to do them even if you find a reasonable change. It's just getting the creative juices flowing for everyone. You seem to take this stuff so personal and get offended. I'm not trying to do that just trying to get ideas flowing. If you were to say "I agree that hidden entities still calculating physics is wasteful" we're not going to slam you for sticking with it. We are just happy that you are aware and maybe somewhere down the line this sparks an idea in you.

[darthlukan]

This doesn't make sense. You want to make the engine more complicated and introduce new bugs because of an extreme outlier situation? This would normally give you perhaps a 0-2% improvement in speed and make everything much more complex to use.

 

Leadwerks will never handle more than a few thousand individual entities in a scene very well. It's not designed to.

 

Beyond that, visibility has nothing to do with physics. If the developer has to worry about which offscreen physics occur and which don't, they are going to be very confused when a door doesn't open when it's supposed to, or some other reaction occurs. When objects are at rest, the physics system is very efficient. It will never accomodate tends of thousands of objects. That's what the vegetation system does.

 

I notice that any time we come out with new models or gameplay additions, people always start wanting to reinvent the engine. It's a pattern that happens every time.

 

It's not a matter of reinventing the engine in this case. In this case, the dev expects to not incur a performance penalty when pre-loading and not rendering entities. Currently, there is a performance penalty, because, as you rightly pointed out, visibility has nothing to do with physics. Just because something isn't rendered doesn't mean it isn't having its physics calculated. That's fine for small games with not very many entities (as you also rightly pointed out) and the engine isn't designed for large scenes with lots of entities (several thousand).

 

Is it complicated to expose a method of control that allows a developer to control that behavior? Yup, if it were easy, everybody would be doing it at home already. Is it something useful and therefore worth considering? Probably.

 

Nobody is knocking your work or purposely trying to get you to fundamentally overhaul the engine here (in this thread). We are interested in having more control over which entities are having their physics calculated as we see it as useful performance-related feature. Obviously you're the gatekeeper of features since you're the one that would have to implement them, we totally appreciate that and understand that you're not some mythical magic wand wielder that can just say a few words and "poof" features into existence. Especially around the holidays

 

IMO, it would be useful, but it's not some super-emergency that has to be decided over the holidays. Get some egg-nog in you and enjoy the family. This thread will wait

[Josh]

The vegetation system doesn't presently allow control of the visibility data, but this will be added. It's slightly more complicated than just disabling the instance at position X,Z. The filter texture is the same resolution as the terrain, but the vegetation can be any density independent from the filter texture. So what you will need to do is retrieve all instances in an AABB, check the grid position of each instance, create models for all instances with the grid position you want to disable, and then set the visibility for that X,Z position to false. For example, if there are five objects being filtered at one pixel and you want to delete one, you will set the visibility to false, recreate four of the instances as models, and the fifth one will just disappear.

 

It might be the case that for trees, disabling visibility at the specific instance's grid position is good enough, because trees are unlikely to be spaced more densely than every one meter.

[Ma-Shell]

In C++ you can get access to a few more functions for manipulating physics by casting m->body (best look at the definition of NewtonDynmaicsBody in Newton.h):

((NewtonDynamicsBody*)m->body)

Furthermore, you can access the NewtonBody-structure which is used internally for all the Newton-functions by doing:

((NewtonDynamicsBody*)m->body)->body

You can then proceed to call any function from the Newton by using this body.

Sadly, I have no idea, whether you can do something like this on LUA.

However, I don't think that the problem lies in the physics, since if I remove the file "pine01.phy", there is no physics-model, as can be seen by issuing

camera->SetDebugPhysicsMode(true);

in App::Start(). The FPS are bad in that case, nevertheless...

 

EDIT:

By "all the Newton-functions", I meant those: http://newtondynamics.com/wiki/index.php5?title=API_Database

Also notice, that you won't see an effect for some, as they get overwritten by Leadwerks in the world-update (I guess).

 

EDIT2:

It IS in fact the physics. You can call

NewtonBodyDisableSimulation(((NewtonDynamicsBody*)m->body)->body);

Doing this with 20000 trees will give me a solid 30 fps on my i5 2500 and gtx970.

Withouth that line, I get like no frames at all...

However, even after the scene has loaded, it takes a few seconds (~20) before the fps stabilize.

[Ma-Shell]

Actually, it's not only the physics, since I get a lot more fps, if I don't create them at all (~80), but disabling the simulation for these bodies increases the fps from like 1 frame every 30 seconds to like 30 FPS, which is still massive.

Also, I noticed, if I delete the phy-file, I also have to wait ~20 seconds after the scene has loaded, before the fps stabilize.

The whole code I inserted into App::Start():

Model* m;
for (int n = 0; n < 20000; n++)
{
m = Model::Load("Models/Trees/pine01.mdl");
m->SetPosition(n, 0, 0);
NewtonBodyDisableSimulation(((NewtonDynamicsBody*)m->body)->body);
m->Hide();
}

 

(You can re-enable physics by calling "NewtonBodyEnableSimulation" with the same parameter.)

Is something like this possible in LUA?

[darthlukan]

@Ma-Shell - You just made some people very happy with that find. Being able to call it via LUA would be a "nice to have", but really, for an operation like this, you're probably needing to perform your lookups in C++ anyways.

[Rick]

Actually, it's not only the physics, since I get a lot more fps, if I don't create them at all (~80), but disabling the simulation for these bodies increases the fps from like 1 frame every 30 seconds to like 30 FPS, which is still massive.

Also, I noticed, if I delete the phy-file, I also have to wait ~20 seconds after the scene has loaded, before the fps stabilize.

The whole code I inserted into App::Start():

Model* m;
for (int n = 0; n < 20000; n++)
{
m = Model::Load("Models/Trees/pine01.mdl");
m->SetPosition(n, 0, 0);
NewtonBodyDisableSimulation(((NewtonDynamicsBody*)m->body)->body);
m->Hide();
}

 

(You can re-enable physics by calling "NewtonBodyEnableSimulation" with the same parameter.)

Is something like this possible in LUA?

 

 

That's a good find! Don't even need to hide models now with something like that. Could make a system where it enables close by physics to the player and disables as the player moves away making physics only apply around the player which should be very efficient if you did it with a grid system to tell what entities to enable/disable.

 

 

I'd like to explore the idea of disabling physics outside of the view range. Maybe there could be a physics "view range" where there is an infinite option to keep physics running on that thing no matter what. That would work great for ground and actors. I mean how many games are going to do some non actor/ground physics thing when the models themselves are outside the players vision? The entire point of doing something cool with physics would be so the player can see it. Movement is based on a navmesh anyway that is pre-generated so during run-time it shouldn't matter to remove physics on obstacles that aren't even visible. I mean what would be the issues with a system like this? I see good benefits in performance with something like this.

 

If you are stacking things that need physics and you're worried about the bottom thing getting disabled which could have the top entity fall down, then make the bottom one infinite in physics view and that'll solve that. By default have all physics in infinite view so it's backwards compatible but having this option does give us options for performance enhancements at seemingly little work. I mean you'd just duplicate the view range idea but for physics bodies.

[darthlukan]

Given that find, I don't think there's anything for Josh to look at implementing (unless he wants to wrap that in a method exposed to LUA and C++ as API calls rather than directly via the Newton libs). I mean, that's the functionality we're looking for and the system provides for it, just not in a documented way, but that can be remedied by a link to the relevant Newton docs.

 

Now if you'll all excuse me, the wife and I have a bottle of Cognac to enjoy

[Rick]

Yeah, the hacky part about it is not being able to assign a physics view range in the editor like we do visual view range. So if that's a setting you want each entity to have then each entity would require a script attached to it or a more hardcoded way to set such a key value. Not ideal, but can be worked around. Would just be a nice to have setting. Ideally, when you take this far enough, it's one of those things where if we could have a generic way to set entity key values it could solve this and some other custom settings for other systems we the users wanted to make. Should just be a tab for Key Values that is a list we can set for whatever we want. The benefit is that it wouldn't require a script since all it's really doing is setting a key value in the map format that gets loaded on map load without having the overhead of a script attached to every object. This is something that has been asked a few times and would be very useful.

[Einlander]

The engine does support checking if an entity is culled: http://www.leadwerks.com/werkspace/page/api-reference/_/entity/entitygetculled-r768

 

So if you keep track of what you loaded, you could always check (if culled) => disable physics

[Rick]

Yeah that's works if you go the route of matching visual to physics. For things like trees having physics on them to near and visual to far would give good performance.

[reepblue]

Such an interesting discussion here. Definitely gonna use this in the future.

[Josh]

Such an interesting discussion here. Definitely gonna use this in the future.

For your game, I would not recommend it, at all. The entity count would not be close to making a difference.

[reepblue]

I would not use it with Vectronic, but I can think of cases of which disabling the physics mesh would be nice to do. Shouldn't having the collision type set to 0 automaticly disable the collision, or would it slow down when/if the user changes it's collision type via script?

[Josh]

Changing the collision type will have no impact on performance.