Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (777)
Games in Android Showcase (231)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Clipping planes in Ardor3D  (Read 12152 times)
0 Members and 1 Guest are viewing this topic.
Offline pepin

Junior Newbie





« Posted 2014-07-14 22:17:08 »

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?






Offline gouessej
« Reply #1 - Posted 2014-07-17 18:57:36 »

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.

Julien Gouesse | Personal blog | Website | Jogamp
Offline pepin

Junior Newbie





« Reply #2 - Posted 2014-07-17 21:37:06 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #3 - Posted 2014-07-18 08:23:40 »

I have the latest one, I know it was discontinued.
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

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 culling 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 obviously  more job, but maybe parallelization compensates for it.
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.

Julien Gouesse | Personal blog | Website | Jogamp
Offline pepin

Junior Newbie





« Reply #4 - Posted 2014-07-18 15:50:06 »

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.



Offline gouessej
« Reply #5 - Posted 2014-07-18 21:53:31 »

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).

Julien Gouesse | Personal blog | Website | Jogamp
Offline pepin

Junior Newbie





« Reply #6 - Posted 2014-07-19 20:50:36 »

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.
 
Offline gouessej
« Reply #7 - Posted 2014-07-19 21:26:38 »

Yes this fork is public but by default Github doesn't show the real clean forks except if you use "fork:true":
https://github.com/search?q=Ardor3D+fork%3Atrue

Mine is still here:
https://github.com/gouessej/Ardor3D

Of course, I succeed in maintaining the JOGL backend Smiley I implemented most of the tricky things in this backend except VAO + the fully shader based pipeline and the support of NEWT Input.

Julien Gouesse | Personal blog | Website | Jogamp
Offline pepin

Junior Newbie





« Reply #8 - Posted 2014-07-21 13:08:05 »

Thanks gouessej!!
Offline gouessej
« Reply #9 - Posted 2014-11-22 17:35:50 »

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.

Julien Gouesse | Personal blog | Website | Jogamp
Pages: [1]
  ignore  |  Print  
 
 

 
hadezbladez (331 views)
2018-11-16 13:46:03

hadezbladez (173 views)
2018-11-16 13:41:33

hadezbladez (329 views)
2018-11-16 13:35:35

hadezbladez (80 views)
2018-11-16 13:32:03

EgonOlsen (2171 views)
2018-06-10 19:43:48

EgonOlsen (2199 views)
2018-06-10 19:43:44

EgonOlsen (1375 views)
2018-06-10 19:43:20

DesertCoockie (2007 views)
2018-05-13 18:23:11

nelsongames (1644 views)
2018-04-24 18:15:36

nelsongames (2294 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!