Hi Preet, > 48 rings and 72
This isn't a particular big mesh at all - the osgparametric example creates a 708x708 mesh for roughly 1 million triangles, it runs at a solid 60Hz on even my 8 year old laptop, so we can safely say that size of the mesh is not a problem. You'd have to have a pretty crappy graphics card and drivers not to be able scale up. What is the hardware?? The OSG viewer will automatically assign a TrackballManipulator when you call viewer.run() and this will set it's home position to the center of your model. As for the coordinates - it's certainly not ideal to use ECEF coords with floats, but all that should happen is you'll get a bit of jitter on the coordinate position. There are ways of solving this - a topic that has been discussed many times before here so just look in the archives for discussion about whole earth databases. Robert. On 1 March 2012 18:14, Preet <prismatic.proj...@gmail.com> wrote: > I think it might be a scale issue wrt to the camera. I just found out > about the OSG_NOTIFY_LEVEL env var, and I get a bunch of messages > about the viewer's drawing traversal: > > cull_draw() 0x988f788 > _clampProjectionMatrix not applied, invalid depth range, znear = > 3.40282e+38 zfar = -3.40282e+38 > end cull_draw() 0x988f788 > > I'm using large scaled units (ie, millions) in the scene. Maybe the > geometry isn't within the camera's frustum, or something like that? I > don't get why change the number of vertices that make up the geometry > would cause a change like that though. > > I construct a spheroid using arguments for parameters that correspond > to latitude / longitude style divisions. The latitude argument defines > how many 'rings' go down one axis of the sphere, and the longitude > argument defines how many 'sectors' each 'ring' is divided into. So if > I specify 36 rings and 72 sectors for each ring, I expect my sphere to > have (36*72) vertices. This works fine. If I up the ante to 48 rings > and 72 sectors, osgViewer won't show the geometry. > > The function I call isn't doing anything special... and seems to > complete fine before being sent to the viewer. > > http://pastie.org/3497231 - line 184 is where I defined the function. > I'm going to > > > Preet > > > On Thu, Mar 1, 2012 at 7:00 AM, Sebastian Messerschmidt > <sebastian.messerschm...@gmx.de> wrote: >> Hi Preet, >> >> can you give us some more details on the limit you are hitting here? >> Also I don't see any hints how your geometry is organized? As a single >> drawable? >> If the latter is the case, I guess you are simply hitting some OpenGL/Driver >> limits regarding the maximum size of a draw array. >> >> cheers >> Sebastian >>> >>> Hiya, >>> >>> I used OpenSceneGraph to generate some straightforward geometry; an >>> ellipsoid representing the Earth. I wrote a function which calculated >>> vertices, normals, texture coords and indices for the geometry. The >>> function takes the number of 'sectors' and 'rings' as arguments to >>> generate spherical geometry. It works fine until I hit some limit as I >>> increase the resolution of the mesh (by passing a larger number of >>> sectors and rings to the function), after which point osgviewer >>> doesn't display the data. There aren't any errors; the geometry just >>> doesn't show up in the viewer. If I go back beyond some threshold the >>> geometry shows up again. What's going on? >>> >>> >>> Regards, >>> >>> Preet >>> _______________________________________________ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
