In Ardor3D the frustum clipping planes are computed in
com.ardor3d.renderer.onFrameChange()
The normals are calculated by just scaling the camera directions left & up,
like the frustum was a prism, instead a pyramid.
It seems to me that culling -that uses these planes- won´t properly work.
Or I´m wrong?
Hi
Which version of Ardor3D are you using? You’re probably wrong, I have used Ardor3D since 2009 and it works like a charm… except that now I’m alone to maintain a subset of Ardor3D as Renanse abandoned it.
I have the latest one, I know it was discontinued.
Yes, Im probably wrong, but I´d like to know why. It seems pretty clear that the code is not computing the normals
of the faces of a pyramid, but a prism.
There is the possibility that this is a bug that would result in rejecting no mesh by clipping. In this case there would by no visual hint of the problem, only that the culliing state “Automatic” is not doing its work, and objects outside the frustum are not filtered, but transformed to the clipping space and rejected there by the hardware.
Another point to consider is if it is worth to allow the cpu to clip in world space, or its faster to let the card do all the transformations and the clipping job. It is obiously more job, but maybe parallelization compensates for it.
Which latest one? The “latest” version available through Maven is Ardor3D 0.9 (Ardor3D will never be updated on Maven Central). The “latest” version available on Renanse’s Github repository is Ardor3D 1.0 “snapshot” but the latest version of a maintained subset of Ardor3D is on my Github repository here:
https://github.com/gouessej/Ardor3D
As I’m alone to maintain a subset of Ardor3D, I would feel better if you could fill a bug report with a short test case exhibiting the wrong behavior you describe. The viewing frustum is a square frustum which is a kind of pyramid.
Please make a separate bug report for your request for enhancement about the clipping in world space in the GPU instead of the CPU. It’s probably a bit late to implement this kind of feature as I’d like to release a stable version next year.
Mine is 1.0-SNAPSHOT as it appears in the pom file.
In fact I’m not describing a wrong behavoir, but some code I think is no correct, or at least I can’t understand.
I will try to make it apparent in an example, I don’t know this will be easy.
Ardor3D is mainly for the fixed pileline case. It includes a few examples with shaders, but they are more an exception than a rule. I feel the current framework is not well suited for a general feature like “world clipping in the GPU”, that would mean using shaders by default.
What I was trying to say is that the Automatic culling mode -in case I’m wrong and it works as promised- might not suppose a great deal in most common cases. It would be noticiable only if you have a huge model and you are zooming on a very small region of it, resulting in many vertices not being sent to the card.
But I’m not saying that frustum clipping is a big burden for the CPU, as it only involves checking the bounding region of each mesh against the 6 planes of the frustum. Whatever the complexity of the mesh, only its boundary is checked, so the test should no be a major problem for the cpu. Only if your scene has a zillion of micro meshes moving around you should be worried about it, and try to clip in the gpu, or simply no clip.
Thanks for pointing to me to your maintained version, I will use it in the future.
Another user forked Ardor3D last year and implemented several important features based on shaders and VAO in order to use a backward compatible profile but he didn’t contributed back probably because a lack of time. We can still implement an alternative code path using shaders, I did something similar to support OpenGL-ES in the JOGL backend without breaking the rest of the renderer but my main concern is the potential bug.
In my humble opinion, it would be better to look at the source code of Goo Engine and use it as an inspiration for Ardor3D 2 but I would like to keep a code path supporting OpenGL 1 instead of dropping its support (which is done in most major recent scenegraphs).
Is this Ardor3D´s fork public? I´d like to have a look but can´t find it.
I hope you suceed in maintaining the jogl part of the Ardor3D code,
it seems no easy, the framework is sometimes hard to follow.
Im still have many things to learn, in particular smooth ways of introducing shaders
in a scenegraph, so i will have a look to Goo Engine as well.
If I find some idea to apply to Ardor3d i will let you know.
Yes this fork is public but by default Github doesn’t show the real clean forks except if you use “fork:true”:
Mine is still here:
https://github.com/gouessej/Ardor3D
Of course, I succeed in maintaining the JOGL backend 
I implemented most of the tricky things in this backend except VAO + the fully shader based pipeline and the support of NEWT Input.
Thanks gouessej!!
Hi
As promised, JogAmp’s Ardor3D Continuation user’s guide is available here. Sorry, it is very long and there are about one hundred examples on Github. Best regards.