www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: Thomas. on March 23, 2012, 08:45:41 pm
-
Is possible for sorting of objects before rendering? frustum culling -> sorting (maybe getter for boolean, be rendered?) -> render
If no, is possible for implement it? :)
-
What should that be good for except reducing performance? Objects will be sorted either by state (for opaque objects) or depth (for transparent objects). I don't see the point of doing this by hand!?
-
distance for fillrate, prevent to setTexture (same texture consecutive), same material...
-
As said in the PM. jPCT already does this for you...there's no point in trying this by yourself.
-
In every frame? Is takes in account distance of object?
-
Yes, but only for transparent objects. For opaque ones, it takes the states (i.e. textures, blending, shaders,...) into account. It's rather pointless to sort by depth in that case (especially on anything but NVidia GPUs), but you can try it with Config.stateOrientedSorting=false;
-
If I understand correctly, for example, in indoor scene, when I sort objects by depth, closer object (maybe wall) can cover all others and demanding shaders like per-pixel lighting or parallax mapping will not calculating? If it is true, it will be big speed-up...
-
No, it doesn't work that way. The depth test happens after the fragment shader has been executed (Edit: Except when the GPU uses early z optimizations). It might still save some cycles due to the fact the the result hasn't to be written into the frame/depthbuffer if it's hidden, but that's usually not an issue. Most current mobile chips are deferred renderers anyway. They do the sorting internally, so there's no point in doing it manually. Sorting by state is usually much more efficient than sorting by depth unless you draw dozens of planes on top of each other. But as said, you can set this flag in Config and see what happens.
-
I see. Thanks for explain ;)
-
Next question. In draw method is everything sent to GPU, after that GPU everything calculation and CPU does nothing? Is it smart create thread before is called draw method and calculating something by CPU?
-
Not unless you have multiple cores available. GPU and CPU are already working in parallel. Drawing a frame isn't just one call...it includes a lot of state changes, shader switches and render calls. While the GPU executes a render call, the CPU already prepares the next batch. With multiple cores, you can do other stuff while the render thread it drawing...but you introduce an overhead, because you have to make sure that the render thread can work on a set of data that the other thread doesn't modify. Creating a thread before starting the rendering isn't smart at all, because starting a thread is very expensive. You have to use a worker thread which is always running instead.
-
Thank you, now I haven't multicore phone, where I can testing, so I try implemented it later...
-
Tegra used early-z optimization.
http://www.nvidia.com/content/PDF/tegra_white_papers/Bringing_High-End_Graphics_to_Handheld_Devices.pdf
edit: also Adreno 205+ https://developer.qualcomm.com/forum/qdevnet-forums/mobile-gaming-graphics-optimization-adreno/1286
and Mali-200 and Mali-400 http://www.malideveloper.com/files/DUI0363D_opengl_es_app_dev_guide.pdf
I can't find any info about PowerVR GPUs...
-
PowerVR is a deferred renderer...it doesn't need cheap tricks like early-z to save fillrate. Anyway, you can give it a try by setting the mentioned switch in Config. But it will most likely be slower than state sorting unless you have only a few state changes but much overdraw.
-
But early-z also save calculating fragment shader not just fillrate.
http://www.slideshare.net/pjcozzi/z-buffer-optimizations ... 9th slide
-
Yes...that's what i said a few posts above. I don't get your point ATM. IMHO sorting by state is more efficient than sorting by depth for the general case. But if you want to try it, just flip that Config-switch and see for yourself. The option is there for you to try. Just keep in mind that this has no influence on single objects because you can't change the in-object draw order. That's why i consider early-z to be a rather inefficient solution of which you can't expect any wonders.
-
But objects can be sorted by dept of group with same texture, inside of group also by depth...
-
Apart from making the sorting more complex, this only applies to objects with exactly the same attributes/states that overlap by a huge amount. How often does this case apply? Exactly...almost never. And if it does, it still isn't any better. You can be sure that i tried a lot of stuff over the years on Android as well as on the desktop. This 'optimization' isn't even micro-optimization...it's pointless and the time spend on it should better be spend somewhere else.