Hi, Rui and Robert
this is not about intersection stuff, but more about fbx plugin
i've made changes to support loading of textures which contained in fbx format but now have not been used in osg plugin (like bump map, specular color and glossiness maps, ambient map and displacement map, and their mix-in coefficients, where applicable), they can't be used directly with fixed-function with regard to correct rendering, but can be used in shaders. So they are now saved in stateset but turned off with setTextureMode(id, GL_TEXTURE_2D, osg::StateAttribute::OFF). If this change seem useful i'd be happy to submit it, but it made on top of patch i've send before and it wasn't accepted yet, and actually i'm not sure i've done things most appropriate way there, but i've got no feedback on my request either.
Cheers.
15.02.2013, 16:40, "Wang Rui" <[email protected]>:
Thanks Robert,It's OK to use RayIntersector for the case of unbounded ray intersection with depth-partition scene and embedded cameras. But my submission just want to return to users the correct global near/far values. For depth partition case, we can manually traverse all slaves and collect them. But for embedded camera case, it seems to be a difficult mission, because currently near/far values computed in cull visitor will neither be re-set to the last camera in stack, nor to the main camera of the viewer.So I think we should at least find a way to return the computed near/far values to user level, for further debugging and testing. Do you think it a better alternative to set the near/far values to the owner camera in CullVisitor::popProjectionMatrix()?BTW, I just found that there were a few topics about the FBX plugin updates. Would it be confusing for you to review and accept them? Do you need some help like collecting all past submissions and resubmitting a complete one? :-)Wang Rui,2013/2/15 Robert Osfield <[email protected]>Hi Rui,
I have just done a review of your change for a GlobalNearFar and it
feels rather awkward and confusing to me. I don't have an alternative
proposal right now, other than the suggests for cases where we have
multiple Cameras overlapping and wish to using picking then one should
use an unbounded ray intersection test rather than a line segment
test. W.r.t RayIntersector submissions, I'm still trying to work my
way through my submissions backlog.
Robert.
On 13 February 2013 08:33, Wang Rui <[email protected]> wrote:
> Hi Robert,
>
> I'd like to submit my changes to fix the "near/far values for intersection"
> problem, which can be obviously found in osgdepthpartition and osgpick (with
> the option --relative-camera-scene) examples.
>
> In the osgdepthpartition example, we can't actually perform correct
> intersection test (in WINDOW/VIEW/PROJ coordinate frames) with earth/sun
> nodes because the necessary near/far values are stored in slaves instead of
> the main camera. I provide a new computeGlobalNearFar() method in ViewerBase
> to obtain a global near/far pair and apply it to the main camera, and update
> the osgdepthpartition example to show how it works.
>
> In the osgpick example with --relative-camera-scene, you will see that when
> picking the cube object, only one result is returned (but of course there
> should be two). That's because the cube is drawn under a post camera in the
> scene graph. The CullVisitor will reset old near/far values every time when
> it finishes traversing a child camera, so the depth data of the cube is
> already lost when we apply getCalculatedNearPlane() and
> getCalculatedFarPlane() to the main camera in SceneView::cull(). I changed
> this behavior by providing the getGlobalNearPlane()/getGlobalFarPlane()
> methods, and now osgpick can work with correct results.
>
> The computed result may not satisfy everyone as it collect all perspective
> projection matrices to get a global near/far pair. But in some cases we may
> want to ignore some of them (e.g., RTT camera matrices). This can be done by
> providing an extra option to the Camera/Projection classes. But at least my
> changes should not affect the rendering work and should be compatible with
> most current applications. So I'm glad to submit them now. :-)
>
> Some months ago, you, PCJohn and me discussed about the idea of infinite
> line intersection (seems that for design pattern reason the RayIntersector
> is not merged to the trunk yet). It could also fix the intersection problem
> in large environments. But the correct near/far values are still not
> returned to users, which may be very useful for debugging and implementing
> frustum-related algorithms. I hope this patch could help.
>
> Cheers,
>
> Wang Rui
>
>> _______________________________________________
> osg-submissions mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
