+- Forums (https://www.vdrift.net/Forum)
+-- Forum: Project (https://www.vdrift.net/Forum/forumdisplay.php?fid=4)
+--- Forum: Development (https://www.vdrift.net/Forum/forumdisplay.php?fid=9)
+--- Thread: performace issues (/showthread.php?tid=1545)
Pages:
1
2
performace issues - alex25 - 08-08-2011
just tried to edit a track that has 65673 objects with no success at all. the track actually loads in the track editor, which kind of surprised me, but the frame rate never made it above 0.0004 frames a second. not too much one can do with that. maybe i'll try tomorrow on my desktop (this was on my laptop). not really sure what could be done to speed up thing anyway.
and speaking of performance issues. lately vdrift has become unplayable (where lately has been since we added dynamic objects and started using bullet for the object trees i think). if i start at spa2008 i get a decent rate on my laptop, around 50-60 fps. but when i round the first corner, the rate drops below 10 fps or even lower and the simulator kind of freezes (there is a lot of stuttering there) and there is no way i can control the car (this is with the F1-02). then the rate picks up only to drop around the next corner and so on. the second time around things seem to be a little bit better but this didn't used to happen. i remember there being some performance issue with an unpatched bullet version (and that's why we had a patched version in the local tree). now that we switched to the system installed library (and i didn't actually see those patches making it upstream) i am wondering if that's the case. any ideas? (this is specially addressed to NaN since he implemented that part of the code). thanks.
--alex--
- NaN - 08-08-2011
Quote:track actually loads in the track editorTrack editor is based on the old implementation hasn't been synced with vdrift code. No idea about its performance limits.
Quote:vdrift has become unplayableCan you try "vdrift -profiling"? It should show you some numbers. I've planned to do some profiling/play-testing after pushing another bunch of fracture code changes.
- alex25 - 08-08-2011
NaN Wrote:really?! you thought i didn't know that? amazing... if it makes you feel better even blender had problems dealing with this track. it's a pity because it looks like a really beautiful one.Quote:track actually loads in the track editorTrack editor is based on the old implementation hasn't been synced with vdrift code. No idea about its performance limits.
did one lap at spa2008 with profiling, this is what it says:
ai: 0.0126807 %
car-update: 1.2467 %
physics: 4.49186 %
render: 83.9912 %
scenegraph: 2.31186 %
this is probably not that informative because things happen only when there are suddenly a lot of objects so i'm pretty sure it is the scene graph.
i just tried another run quitting right after the first turn:
ai: 0.00588349 %
car-update: 0.579721 %
physics: 2.23063 %
render: 66.2563 %
scenegraph: 1.37874 %
not sure where 30% went, maybe it was all the freezing.
anyway, so what happened to the patches you had for bullet to speed up the scenegraph? i never saw them making it into bullet upstream and i remember a message you posted (which i can't find right now) where you said that the time difference between the two was pretty big.
--alex--
- NaN - 08-08-2011
The scenegraph is graphics.
Quote:patches you had for bullethttp://code.google.com/p/bullet/source/detail?r=2300
There has been another VDrift related modification(hack). But I didn't consider it as relevant to upstream. Ironically we are not using this code path anymore. The relative speed difference is about 200-300%. In absolute values you would have < 2% physics instead of 4%. Back then I saw any performance regression as a bug.
Quote:it's a pity becauseCan you upload it to data? It would make a good benchmark even if it is unplayable.
- alex25 - 08-08-2011
NaN Wrote:The scenegraph is graphics.
Quote:patches you had for bullethttp://code.google.com/p/bullet/source/detail?r=2300
There has been another VDrift related modification(hack). But I didn't consider it as relevant to upstream. Ironically we are not using this code path anymore. The relative speed difference is about 200-300%. In absolute values you would have < 2% physics instead of 4%. Back then I saw any performance regression as a bug.
there has been a major regression in rendering/creating the scenegraph. i looked at the numbers again on my laptop, the framerate drops from 80-90 fps at startup to <10fps with major freezes right as i turn the first corner. to me it looks like this is happening when new objects are added to the scenegraph, and this is not done very optimally. it didn't use to happen.
NaN Wrote:Quote:it's a pity becauseCan you upload it to data? It would make a good benchmark even if it is unplayable.
i'm trying to get permission from the authors to convert it to vdrift. if i get it, i'll upload it even if i can't do any editing on it. i'm very busy at work today but in the next few days i will try to play with it on my desktop.
--alex--
- alex25 - 08-08-2011
i think i found the old discussion: http://vdrift.net/Forum/viewtopic.php?t=1517&postdays=0&postorder=asc&start=15, it had to do with ray queries for compound objects. the tests you had back then for lemans gave this:
objects(current): 27.871 ms, should be better theoretically, has dbvt for static objects
compound(new): 2.774 ms
compound(unpatched): 184.218 ms, O(rays*objects)
you had a patch to speed up bullet, and it is this patch that didn't make it in upstream. are you saying we are not using this any more?
--alex--
- NaN - 08-08-2011
Quote:i'll upload it even if i can't do any editing on itCool. I've thought about exporting only the road meshes for the track editor to trace the roads and set the start positions, hoping that the other stuff can be done in blender.
Quote:compound(unpatched): 184.218 msUpstream patch: http://code.google.com/p/bullet/source/detail?r=2300
Quote:objects(current): 27.871 msI've missed a switch at that time. Bullet hasn't really got a documentation. The time with the switch enabled is more like 3x compound patched. This code path is used now.
- alex25 - 08-08-2011
NaN Wrote:Quote:i'll upload it even if i can't do any editing on itCool. I've thought about exporting only the road meshes for the track editor to trace the roads and set the start positions, hoping that the other stuff can be done in blender.
Quote:compound(unpatched): 184.218 msUpstream patch: http://code.google.com/p/bullet/source/detail?r=2300
Quote:objects(current): 27.871 msI've missed a switch at that time. Bullet hasn't really got a documentation. The time with the switch enabled is more like 3x compound patched. This code path is used now.
blender is just as slow (at least on my laptop) so i wouldn't hold my breath. what i used to do in the past (for the ring for example) was just load the track objects in the track editor and that helped a lot. the rest i do with listedit (using blender for that kind of stuff is overkill).
what is the switch? do i need to set something when compiling bullet? right now i set the build_type to Release but everything else is the default.
--alex--
- NaN - 08-08-2011
Should have been more specific. It's not a compiler switch. It is a object setting(setActivationState(DISABLE_SIMULATION)). It has been enabled already, else physics would be way too slow.
- joevenzon - 08-15-2011
Based on your profiling I don't think it's the physics. It makes sense that it's the rendering. 65,000 is too many objects! The track editor is choking on it because it's so old that it doesn't have any of the performance improvements from the scenegraph rewrite forever ago. I think processing 10k objects is about as high as we can reasonably support per frame. Is this track really big or just really detailed? If it's really big then the solution would probably be some sort of system to defer loading far off objects (currently far off objects aren't drawn, but they are loaded into memory). If it's really detailed, the solution would probably some system to automatically merge together nearby objects (trying to merge objects with similar materials first, but merging textures into an atlas if necessary).
- joevenzon - 08-15-2011
Oh, and about spa2008, the performance of the gl3 renderer might be slightly slower than the gl1 and gl2 renderers, although I'm not sure what's getting enabled for you. If GL1 or GL2, the only thing I can think of that would have slowed it down is that I have been tweaking the value of OBJECTS_PER_NODE in staticdrawables.h. It used to be 1, I think. It might be interesting to see if changing that has an effect on perf for you.
- FFuser - 08-15-2011
Quote:(where lately has been since we added dynamic objects and started using bullet for the object trees i think)
What are these dynamic objects? Because I see people talking about it, but I don't know what it is...
From the name I guess it are (for example) cones on the road, and that when you hit them instead of the car flying away (as sometimes happened in older versions of VDrift, and even Racer), the cones fly away.
Am I right? Are their any tracks using this? (And if so, which ones?)
- NaN - 08-16-2011
Rouen has a single object for testing purposes. The implementation has to be supported by the editor or blender plugins to be really usable.
- alex25 - 08-17-2011
joevenzon Wrote:Oh, and about spa2008, the performance of the gl3 renderer might be slightly slower than the gl1 and gl2 renderers, although I'm not sure what's getting enabled for you.i'm pretty sure i'm using the gl3 renderer. how can i switch to the gl2 one to see if it makes any difference?
--alex--
- joevenzon - 08-18-2011
I just checked in a change to add a -gl2 argument that will force the opengl2 code path (although it'll still fall back to gl1 if you have shaders off or you card doesn't fully support the features required).