Hi,
I am now testing possibilities of migrating my [huge] project to new Xith3D codebase, and have few questions [mostly to Marvin] related to some architectural decisions made:
Yuri
Hi,
Another note: if I switch off bounds calculations globally (i.e. use Node.setGlobalIgnoreBounds(true)) because of I 100% know all my shapes always fit the screen (I simply do not need bounds - they are only practically needed for culling), picking fails with NPE.
You commented out glSelect-based picking, which I believe works faster for complicated geometry-based picking because of it works on the triangle level and at least accelerated by driver native code(OK, imagine I want to pick a particle in a particle system only if I really hit particle; particle system is a single shape and has 10,000 particles).
I believe we should leave both picking methods - pure software and glSelect, because of there are cases when one is usable while other is not.
Yuri
Hi,
Implementation of PickResults returned by Canvas3D.pickAll(…) drops important information neccessary to make decision which shape is closer to the viewer: it returns middle point of the min/max intersection points, and this is definitely not enough to make decision of which shape to pick in case of mutually intersecting shapes: small cube can be much closer to the viewer than the center of the bigger cube and INSIDE the bigger cube, thus completely invisible but mis-picked basing on the middle point information.
PickResults have to be extended to hold original picking result values.
Yuri
BranchGroup is used for RenderPass administration. It can be used inside the scenegraph, but a warning is dumped to stderr. So not a real problem for backwards compatiblity.
I don’t know, if I understood you right. But sorting policy is not in the RenderPassConfig but in the Renderer.
I forgot this thing and will change it. What is NPE?
That’s wrong. The distance property of PickResult holds the zMin value of glSelect picking.
The reason, why I didn’t post the reactivation of an extremely improved glSelect picking is, that I’m not completely ready and I first want to wait until we’re on sourceforge and I changed the core package names to org.xith3d, too. gl-picking was considered to be too slow, because of a tumb glSelect-name-to-shape mapping. I changed it to be a lot faster. And - as you already found out - moved it to Canvas3D.pick*().
Marvin
Hi,
[quote]That’s wrong. The distance property of PickResult holds the zMin value of glSelect picking.
[/quote]
(from CanvasPeer.java)
float dist = zMin + ((zMax - zMin) / 2.0f);
dist = zMin;
results.add( new PickResult( shape, dist ) );
That’s a midpoint. I suggest to add both zMin and zMax, as well as use lazy creation of tmpTrans in PickResult.java.
I anyway working on it now, so I can post the results to the CVS.
Yuri
Again the question: What is NPE?
(from CanvasPeer.java)
float dist = zMin + ((zMax - zMin) / 2.0f);
dist = zMin;
results.add( new PickResult( shape, dist ) );
That’s a midpoint. I suggest to add both zMin and zMax, as well as use lazy creation of tmpTrans in PickResult.java.
[/quote]
float dist = zMin + ((zMax - zMin) / 2.0f);
That’s indeed a midpoint.
dist = zMin;
That’s zMin ;).
I did it this way the avoid Eclipse warnings. Of course it’s not the most elegant way.
OK. But with what values to you want to fill zMin and zMax if picked with PickingLibrary?
Marvin
Hi,
[quote]That’s zMin
[/quote]
Ooops… Sometimes even I am completely blind 
zMin and zMax can be the same if not determined by picking library, but if we get the value from underlying system I believe we should let users get access to it.
Yuri
Hi,
Can somebody explain the reasons of disabling glSelect picking for Parallel Projection?
// never pick on PARALLEL projected atoms
Yuri
I previous version problems always arose with picking in parallel projection. I guess it is due to a missing gluPickMatrix() function for parallel projection. In fact, picking can be done faster in parallel projection. And in most cases you’ll use HUD or something like that for the parallel part. And the HUD system uses it’s own picking system.
Marvin
Hi,
In one of my projects I use Parallel Projection with quite complicated geometry, no bounds, no culling, no background clear etc., so I can confirm that Xith3D picking was working quite good in previous versions (actually, I added glSelect based picking to Xith3D) - it can be tested in simple picking example available as JWS app on xith.org.
Now I am trying to fix glSelect picking to reach at least the same functionality level as it was before, so I believe I am coming soon with fixes.
There are some strange effects with pickable non-renderable nodes - this is what I am trying to fix at the moment, preferrably leaving the rest unchanged.
There are some inconsistences in rendering of the nodes switched off with setRenderable(false), but it is supposed to be a next step.
Yuri
It’s so good to see someone else actually having a closer look and working on the rendering code :).
Hi,
Looks like I already have a fix for glSelect picking in Parallel Projection, but I can’t submit it until I fix also pickable non-renderable issue - I still have no proper visual results (I get picked shapes that marked as pickable=false (though, they should not even be rendered duting picking pass))…
Yuri
I just added support for minimum-, maximum- and medial distance to PickResult.
Yuri, maybe you could help me with the DisplayList improvement. Please have a look at the most recent changes. I tried to call executeShaders() from within the ShapeAtomPeer, which resulted in strange effects in HUD3DTest. I don’t get it, why it doesn’t work. And I think it is really important, since it promises a really huge performance boost. So if you can spare a little time, please have a look.
Marvin
Hi,
I was thinking to put my hand a bit to improve performance in Quake benchmark, but practically have bunch of problems with my existing codebase at the moment… so first I plan to fix topics top-urgent for me (i.e. finalize migration to the new codebase and add ability to copy-to-texture at the end of the pass, so we can use a kind of CTT with possible extension to RTT).
If some problems with display lists will show up in my code, I will check them immediately. And before submitting pick fixes I will check if I did not break anything in HUD3DTest with my changes.
Yuri
OK. Thanks.
I think, I have an idea, why you’re not getting any pick result when picking on parallel…
Please check, if you correctly adapted the select-name-offset-generation. The actual select-name pushed to the select-buffer is the current array-index of the shape in the renderbin shifted by an offset. The offset is calculated by adding the previously rendered bin size to the current offset. And I left the parallel groups out of this offset. So this point needs to be changed in CanvasPeer.getAtomByGlobalIndex() and some methods on CanvasPeerImpl, if not already done by you.
Does this help you?
Marvin
Hi,
I believe my problem is caused by the fact that scenegraph is not re-traversed upon picking mode activation. I get proper shapes (at least shapes on the right positions) picked, but they are
my visual shapes, not those pickable sensors (sensors are not renderable but pickable).
Now I am looking for a correct way of triggering the re-traversal.
Yuri
P.S. I am using pickAll() methods in Canvas3D now, anyway.
You’ll have to call the cullAtoms() method from within the pickAll() method. You’ll have to add some getters to make is accessable from there. And don’t forget to increment the current frame-id in Renderer before invoking this method.
Marvin
EDIT: If you want, I’ll do that for you.
Hi,
[quote]If you want, I’ll do that for you.
[/quote]
Thanks, but I have to get familiar with core internals in details.
Yuri
Hi,
I already localized the problem and now working on a fix for it.
BTW, I have the question: doesn’t it make sense to make all cullAtoms(…) except cullAtoms(Universe, …) private? I just think where to place few extra checks and want to ensure architectural consistency, so we know we fixed this picking problem once and forever.
Yuri