Hi Rui & Sergey, Having one update for the fbx plugin would be preferable if all the changes are from one user, but if each set of changes might be independent enough or might require reverting at some stage then having them as separate submissions could be better.
As for loading data not supported by fixed function pipeline, I'd suggest load it and leave all the state in a normal state and don't worry about the inappropriate rendering. One could possible add a osgDB::Option's argument to toggle on/off handling of this extra data. Another route one could data with extra data is to use osg::Object::UserValue support to pass back hints about the shaders required and any extra data that might be appropriate. Robert. On 15 February 2013 13:35, Sergey Polischuk <[email protected]> wrote: > 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 > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
