Re: [osg-users] Best ways to render FE models with millions of tris and quads
Hi there, From my (short) experience with OSG, to reduce memory consumption, get the number of vertices down (Optimise geometry using TRI_STRIP), share state sets (or just use vertex colours for shading) and as you said turn off display lists. Also reduce (or remove) Transform nodes. As for optimisation, yes you say that you will lose the ability to pick a primitive, but could you perhaps write your own picking IntersectionVisitor that first picks by Geode, then drills down into the triangle and updates the vertex colours just for that tri? Take a look at IntersectionVisitor, SmoothingVisitor, TriangleFunctor as these deal with triangle-level geometry. Hope that is helpful, Andrew On Mon, Nov 16, 2009 at 8:04 PM, Andrew Cunningham o...@a-cunningham.comwrote: Hi, I am struggling with the most efficient way to render finite-element models with the best speed/memory tradeoff. These models may have milllions of nodes and elements ( triangles and quads), with usually simple shading. I am replacing some custom OpenGL code (hard to maintain, not clean C++) with OSG ( easy to maintain, well written C++) For example, with one particular model, the old custom code which basically just held a vertex array and sent the primitives down the pipeline used about 650M of memory. The OSG version with no optimization of the primitives and using display lists used 1.3G of memory. Turning on optimization, and turning off display lists brought that down to 850M. Turning display lists back on, cost about 200M. The big problem with optimizing the geometry , is that one loses the ability to pick as all association of the primitive index with the original geometry is lost... Obviously there is always a memory/speed trade-off here, but perhaps someone has been this way before and has some best practices advice. Thanks Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19712#19712 ___ 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
Re: [osg-users] OsgViewer and Windows Forms
Hi there, I'm doing something very similar - OSG hosted in .NET. The way I've done this is I have my render thread running in a loop and instead of rendering continuously, I have a StackRenderArgs hosted in the OSG .NET control. Then if I want to render, I push a RenderArgs onto the stack. Inside the render thread, I check if there is an item in the stack, if so, pop it out and render. That way I have control over rendering (I only render when I need to in my app, as its a visualisation and doesn't need to run continuously). Also in the render thread, if there are no stack objects I will Thread.Sleep(1) to pause the render thread for 1ms (The minimum allowed time). This is just one solution. You could alternatively call frame directly and just use some object to handle the thread locking (Lock keyword in C# or Monitor::Enter/Exit in C++/CLI). Calling frame from within MainForm_Paint is not that bad an idea, I've donet his myself for DirectX visualisation applications before. Cheers, Andrew On Tue, Nov 10, 2009 at 3:48 PM, Smelik, R.M. (Ruben) ruben.sme...@tno.nlwrote: Hi Todd, I've had the same choices to make for my .NET / OSG program. I'm not sure whether or not the .NET timer / Invalidate is a stable approach, FYI I'll just explain the solution I've chosen. To avoid all the mutexes and threading issues, I went for a very simple solution. A render thread loops to call frame() and a UI thread processes user actions. Changes to the scene graph are made in two steps: * The UI thread sets a flag indicating what kind of change to the scenegraph is required; * Each iteration, the render threads checks (and clears) all flags and makes the required scenegraph changes before calling frame(). Of course, depending on your application, this can be kind of awkward (although you can replace flags with more detailed modification objects containing loaded models etc.). Kind regards, Ruben From: osg-users-boun...@lists.openscenegraph.org on behalf of Todd J. Furlong Sent: Tue 11/10/2009 4:11 PM To: OpenSceneGraph Users Subject: [osg-users] OsgViewer and Windows Forms I have a .NET Windows Forms application with 2 OSG-based classes: 1. A UserControl/OsgViewer based class, and 2. An OSG-based engine that handles file loading, scenegraph mods, etc. The .NET example from the OSG website gets the viewer initialized: http://www.openscenegraph.org/projects/osg/wiki/Support/FAQ#HowdoIembedanOSGviewerina.NETcontrol My question is: What is the best way to call the viewer frame function in this application? I have tried updating the viewer in a new thread. It appears to perform well, but it presents thread safety problems because my scenegraph modifications (from the engine) mostly take place in the UI thread (button press events, etc). I can simplify the engine code (avoid mutexes around function calls) if I can get the viewer to update on that thread. To move the viewer onto the UI thread, I am calling the viewer frame function in an override of the OnPaint method of the UserControl class. I've created a Forms timer that periodically calls Invalidate on the UserControl to make sure OnPaint is called with some regularity. Other timer-related code insures that the Invalidate call isn't made at a greater frequency than we expect the viewer to be able to render. It appears to be working OK, but I'm worried that this approach will be fragile as we run this application on different systems with different scene contents. Comments or suggestions? Thanks, Todd ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org https://tnoportal.tno.nl/listinfo.cgi/,DanaInfo=lists.openscenegraph.org+osg-users-openscenegraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ 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
Re: [osg-users] OsgViewer and Windows Forms
Yes, just thinks like Maximise, Minimise, Resize. I also rendered on Activate in case the form lost and regained focus. There's no problems integrating OSG with .NET Windows Forms from what I can see. On Tue, Nov 10, 2009 at 4:11 PM, Todd J. Furlong t...@inv3rsion.com wrote: Thanks for the responses. Ruben: That sounds like a robust way to handle threading issues. We do something similar in VR Juggler based applications where one thread receives input but many have to render. Andrew: Did you have to hook up a lot of UI events to get your scene to refresh during window relocation, etc? We considered not rendering continuously to get around ToolTip transparency issues, but it seemed like it might be complicated to get the control to render when it needs to. -Todd On 11/10/2009 10:56 AM, Andrew Burnett-Thompson wrote: Hi there, I'm doing something very similar - OSG hosted in .NET. The way I've done this is I have my render thread running in a loop and instead of rendering continuously, I have a StackRenderArgs hosted in the OSG .NET control. Then if I want to render, I push a RenderArgs onto the stack. Inside the render thread, I check if there is an item in the stack, if so, pop it out and render. That way I have control over rendering (I only render when I need to in my app, as its a visualisation and doesn't need to run continuously). Also in the render thread, if there are no stack objects I will Thread.Sleep(1) to pause the render thread for 1ms (The minimum allowed time). This is just one solution. You could alternatively call frame directly and just use some object to handle the thread locking (Lock keyword in C# or Monitor::Enter/Exit in C++/CLI). Calling frame from within MainForm_Paint is not that bad an idea, I've donet his myself for DirectX visualisation applications before. Cheers, Andrew On Tue, Nov 10, 2009 at 3:48 PM, Smelik, R.M. (Ruben) ruben.sme...@tno.nl mailto:ruben.sme...@tno.nl wrote: Hi Todd, I've had the same choices to make for my .NET / OSG program. I'm not sure whether or not the .NET timer / Invalidate is a stable approach, FYI I'll just explain the solution I've chosen. To avoid all the mutexes and threading issues, I went for a very simple solution. A render thread loops to call frame() and a UI thread processes user actions. Changes to the scene graph are made in two steps: * The UI thread sets a flag indicating what kind of change to the scenegraph is required; * Each iteration, the render threads checks (and clears) all flags and makes the required scenegraph changes before calling frame(). Of course, depending on your application, this can be kind of awkward (although you can replace flags with more detailed modification objects containing loaded models etc.). Kind regards, Ruben From: osg-users-boun...@lists.openscenegraph.org mailto:osg-users-boun...@lists.openscenegraph.org on behalf of Todd J. Furlong Sent: Tue 11/10/2009 4:11 PM To: OpenSceneGraph Users Subject: [osg-users] OsgViewer and Windows Forms I have a .NET Windows Forms application with 2 OSG-based classes: 1. A UserControl/OsgViewer based class, and 2. An OSG-based engine that handles file loading, scenegraph mods, etc. The .NET example from the OSG website gets the viewer initialized: http://www.openscenegraph.org/projects/osg/wiki/Support/FAQ#HowdoIembedanOSGviewerina.NETcontrol My question is: What is the best way to call the viewer frame function in this application? I have tried updating the viewer in a new thread. It appears to perform well, but it presents thread safety problems because my scenegraph modifications (from the engine) mostly take place in the UI thread (button press events, etc). I can simplify the engine code (avoid mutexes around function calls) if I can get the viewer to update on that thread. To move the viewer onto the UI thread, I am calling the viewer frame function in an override of the OnPaint method of the UserControl class. I've created a Forms timer that periodically calls Invalidate on the UserControl to make sure OnPaint is called with some regularity. Other timer-related code insures that the Invalidate call isn't made at a greater frequency than we expect the viewer to be able to render. It appears to be working OK, but I'm worried that this approach will be fragile as we run this application on different systems with different scene contents. Comments or suggestions? Thanks, Todd ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org https://tnoportal.tno.nl/listinfo.cgi
Re: [osg-users] Computing Normals for Drawables
Hi guys, Interesting conversation on solving this problem. I'm working with James on this and he's away this week, so I thought I'd reply to keep the conversation going, and also to thank you for your input. Just to throw another requirement into the mix, I don't think we can use vertex shaders, as we cannot guarantee what hardware the software will be run on. Basically integrated graphics is the lowest possible hardware, so what's that, DirectX 8? 9? Vertex shaders run on DX8 but you won't get many instructions. Can this not be done on the CPU side only? Interestingly we did float the idea of computing a shared normal array (a sphere coated with normals) for all objects in the scene, then provide indices between Geometry vertices and the shared normal array, however we really didn't know if this was possible in OSG, or if it would work. A quick look at osg::Geometry source code there is a function setNormalIndices, so perhaps if we were to create a NodeVisitor that did the following this could work? 1. On creation of the nodeVisitor, create an osg::Vec3Array for shared normals. Populate with normals in all directions. 2. As the NodeVisitor walks the tree, for each Geometry object use the code from SmoothingVisitor to calculate what the normal should be 3. Rather than store that normal in an array and pass to the Geometry, instead find the closest normal to it in the shared normal array, 4. Store the index to the shared normal, and finally set the indices on the Geometry using setNormalIndices This would be done once on load or creation of an object. It wouldn't matter to take the performance hit once per load, nor would it matter if this slowed down rendering. We already employ aggressive use of culling to achieve decent rendering framerate when the object count is high. The hard limit is memory. Thanks a lot for your input, Regards, Andrew On Sat, Nov 7, 2009 at 7:46 AM, yann le paih lepaih.y...@gmail.com wrote: Hi, Interresting links about compact normal and more : http://aras-p.info/blog/2009/08/04/compact-normal-storage-for-small-g-buffers/ http://aras-p.info/texts/CompactNormalStorage.html and http://c0de517e.blogspot.com/2008/10/normals-without-normals.html yann On Fri, Nov 6, 2009 at 10:51 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Simon, Ah I didn't know that, ty. Seems like an odd limitation though. Well, the video cards are implemented to take in only certain types of data. Vertices, normals and colors are in general aggregates of 32-bit floats (which is why no vertex type is ever a vector of 3 doubles). How does the angles thing work? Not sure I follow you. Your intuition is right that normals around a vertex will always be in a sphere. The thing is that you can encode that as spherical coordinates ( http://en.wikipedia.org/wiki/Spherical_coordinates), where r = 1 (since a normal is always unit-length). So the direction could be encoded as two angles, theta and phi, inclination and azimuth (see the Wikipedia article). Now, you already save one float that way over storing a 3-component vector. If you want to save more, since the angles are small numbers, you can store both of them into the lower and upper parts of a single 32-bit float (two 16 bit numbers) and re-extract them from the float in the shader. Another way is you could store only 2 of the 3 components of the normal - since a normal is unit-length you can calculate the third component easily. Those numbers will also be small (less than or equal to 1) so you could do the same transformation into two 16-bit values and store them into a single float. The spherical coordinates just came to mind first as I've used it before, but the result would be the same. If you did the normal lookup, wouldn't you save a whole load of shader processing time, or is memory bandwidth a bigger limitation with shaders? You'd save a little bit of processing time per vertex, but compared to a texture lookup to get the right normal from the lookup table, I don't know what would win. Seriously, what I've described above is child's play for a GPU, and very easily parallelizable, which is what GPUs do best. It's not really a matter of bandwidth since your lookup table would be pretty small too. I expect you'd get similar performance in both cases, for me it's just inconvenient to drag around an extra table when I don't have to - the angles / quantized vector method above would all fit nicely in the object itself without needing any extra data. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org --
Re: [osg-users] Computing Normals for Drawables
Hi there, Jean Well you're kind of juggling conflicting requirements. You want the app to run on low-end graphics, but you want to reduce its CPU-side memory usage to a minimum by not storing normals. Well it's just a typical project really, everyone wants the moon on a stick and they don't understand the concept of engineering compromise! I think the overriding limit is memory usage. If the app cannot load the models it needs to, then its no good. Rendering performance is quite good (we aggressively cull and get 35 frames per second on an nVidia 9600. The most amount of time spent is cull) and so long as the frame rate remains above 5 FPS (ie: just about interactive) its ok ... *Simon Hammett* The only way to do it with the fixed pipeline I can think of, is basically just sort all your geometry into group's by the approximate normal, then you don't have to store the normal index at all so you'd save more memory. Simon I'm not sure I 100% follow what you're saying here. Could you clarify what you meant? Ok thanks all for your excellent suggestions. I think I will take a look at implementing an Index to shared Normal Array using setNormalIndices, even if this drops us down to slow paths, as I would be interested to see just how bad an effect it has on performance. If it's several orders of magnitude, well I will chalk that up to experience and move on. The other idea I like is to use the same method (Indices to normals) in a vertex shader. Not quite sure how I will do this but I believe the hardware we are operating on will be Shader Model 1.0 or 2.0 as a minimum. Thanks a lot, Andrew On Mon, Nov 9, 2009 at 2:14 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Andrew, Just to throw another requirement into the mix, I don't think we can use vertex shaders, as we cannot guarantee what hardware the software will be run on. Basically integrated graphics is the lowest possible hardware, so what's that, DirectX 8? 9? Vertex shaders run on DX8 but you won't get many instructions. Well you're kind of juggling conflicting requirements. You want the app to run on low-end graphics, but you want to reduce its CPU-side memory usage to a minimum by not storing normals. Generally you have a trade-off to make by using more memory and getting good performance, and getting lower performance but using less memory. That's just the way it goes, but you'll have to try to know for sure. No one has a situation exactly like yours, we can only offer guidance. We've given you a few different alternatives, now you have to weigh the pros and cons yourselves. Perhaps try a few of the alternatives in a little test program before making changes in your software itself, and test the alternatives in realistic settings (with lots of objects for example) looking at the stats each time. If you really want to use normal indices, try it out, but as Robert said (and I and others have said before in this thread) this will drop you down to slow paths. If that's good enough for you, then fine, but you won't know unless you try it. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.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
Re: [osg-users] How should I organize the scene graph to handle 2 million points and lines?
Sorry to butt in the conversation here, but I also am working on an app with memory issues and we are considering Paged LOD. For a scene with millions of objects, won't there be a huge performance hit as geometry is loaded/unloaded? I imagine the sort of scene like a city scape where detail is controlled very nicely. That's good as occlusion means not too many things will be visible at any one time. However what in the case of points and lines as the user above has posted? Surely in this case loads will be visible at once, there will be no occlusion, and if you sweep around with the camera, literally thousands of objects will get paged in/out? Or am I being a complete noob and interpreting the way PagedLOD works? Cheers! Andrew On Tue, Nov 3, 2009 at 8:36 PM, Angus Lau angus@safe.com wrote: Hi, Thank you for both of your help. It seems that PagedLOD is what I need to use to reduce CPU memory usage. I have tried to use PagedLOD briefly before, but I am not clear how I can make PagedLOD unload the unused child nodes once those child nodes are loaded. It seems that my PagedLOD nodes do not remove the nodes once it creates the child nodes. Could you please give me some explanation about the proper way of using it?? Thank you! Cheers, Angus -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19123#19123 ___ 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
Re: [osg-users] PositionAttitudeTransform - rotation and translation
Hi there, I don't have an answer for you but I'm working on the same thing now. This is my thread (with no answer yet) http://forum.openscenegraph.org/viewtopic.php?t=3845 The solution I proposed there doesn't quite work. If you get/set the individual components then it breaks it. I am also trying to use Matrix::decompose to get the components out of a matrix, but so far no luck. I'll be listening in here and if I find anything I'll post. Cheers, Andrew On Fri, Oct 23, 2009 at 4:34 PM, Ash Pat ash_zz...@yahoo.com wrote: Hi, I'm using PositionAttitudeTransform to add multiple instances of a geometry node. It appears that the rotation and translation are specified with separate methods, setAttitude() and setPosition() respectively. Is that correct? Can it somehow be done with a single matrix like in homogeneous coordinates? Thanks in advance, Regards, AP -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18629#18629 ___ 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
Re: [osg-users] PositionAttitudeTransform - rotation and translation
Yes i'm probably trying to do something different to you. I want to get/set by matrix as well as position, attitude, scale. If you want just to set/get by matrix alone then as mentioned osg::MatrixTransform does the job. Cheers! Andrew On Fri, Oct 23, 2009 at 5:06 PM, Mourad Boufarguine mourad.boufargu...@gmail.com wrote: Hi Ash, You can use MatrixTransform instead of PositionAttitudeTransform. Then you have access to the transform matrix. Cheers, Mourad On Fri, Oct 23, 2009 at 5:34 PM, Ash Pat ash_zz...@yahoo.com wrote: Hi, I'm using PositionAttitudeTransform to add multiple instances of a geometry node. It appears that the rotation and translation are specified with separate methods, setAttitude() and setPosition() respectively. Is that correct? Can it somehow be done with a single matrix like in homogeneous coordinates? Thanks in advance, Regards, AP -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18629#18629 ___ 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
Re: [osg-users] how to improve frame rate of my scene with lots of cubes and cylinders?
Hi there, this is a quick response as i'm on my pda If you look in the implementation of shapedrawable, drawcylinder function, i believe the vertex locations for cylinders are calculated on each draw, using sin and cos! Also note the matrices for positionattitudetransforms are computed per frame You may be better off creating your own cylinder object with the vertices pre calculated Cheers, andrew On 9/29/09, Maurizio Lodo maurimaur...@msn.com wrote: Hi, I suppose you get many messages like this, so I apologise in advance. My scene is made of cubes and cylinders generated using ShapeDrawable. First I generate a large cell made of 1000 large cubes and up to 3000 cylinders and then a smaller cell made of the same number of elements, just smaller. Then I use osg::PositionAttitudeTransform to place several (16 to 64) of these smaller cells inside one of the cubes of the larger cell. Unfortunately this seems to cause the frame rate to drop to about 8 - 9, while the scene runs at about 120fps when section with the small cells goes out of the screen. I followed a suggestion I read on this forum and I tried to remove the use of osg::PositionAttitudeTransform and draw all the elements of the several smaller cells but this only makes the program take longer to load, but once it's loaded it still runs at about the same frame rate. I am just a beginner and I was wondering if any of you clever people can give me a pointer in the right direction or indicate some useful documents that my help me make this run a little faster. Thank you very much in advance! Cheers, Maurizio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17696#17696 ___ 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
Re: [osg-users] osgUtil::simplifier parameters
Hi there, I've experimented with the simplifier, but am not using it. I found the setSampleRatio() method affects how coarse or fine a result you get. The simplification with a sample ratio less that 1.0 appears to be destructive (i.e. Geometry out does not equal Geometry in). So far I've not found the right settings to be beneficial for my needs (which is reduction of memory consumption while keeping the mesh the same or similar). Another way of reducing the vertex count in your scene is to use the Optimizer. Here I have found that using the Optimizer with the options MERGE_GEOMETRY, CHECK_GEOMETRY and TRISTRIP_GEOMETRY can significantly reduce the number of vertices/primitives in each Geometry object, while giving you essentially the same mesh out. On Mon, Sep 21, 2009 at 10:10 AM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Up ? No one does osg simplifications ? Thanks, Vincent. 2009/9/17 Vincent Bourdier vincent.bourd...@gmail.com Hi all, Using the osg simplifier on a geometry, I'm just surprised to see that there is no way to set a level of simplification or something like that. Maybe I didn't saw it, but for the moment I just found _sm-setDoTriStrip(true); //what for ? do triangle strip are more optimized ? _sm-setSampleRatio(?); //what does it mean ? what does it changes ? ... How can I control the simplification level ? Is this simplifier a destructive one ? (can deform the geometry) Thanks. Regards, Vincent. ___ 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
Re: [osg-users] 3D HUD Elements
Hi Jimmy,
I just stumbled across this thread when searching for a similar solution,
and found it very interesting. Would you be prepapred to share some of your
code for a 3D Axis in the HUD? I'd understand if not.
Otherwise - what is the basic principle?
I have a HUD added to my scene as a seperate camera, this uses an ortho2D
projection and an identity view matrix as in the osgHUD example.
On this I'd like to add a 3D Axis. Should I just create the Geode for the
axis (with an update callback to reorient it) and plop it in the lower left?
Or do I require a separate HUD for the 3D element?
Thanks in advance,
Andrew
On Thu, Aug 20, 2009 at 9:04 AM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi Jimmy,
If you are doing the frame loop you know when it's the first frame
before you just place any viewer setup prior to the frame loop. The
_firstFrame code block you see if just a fallback in case the viewer
hasn't already been setup.
Robert.
On Wed, Aug 19, 2009 at 10:49 PM, Jimmy Lindummy...@gmail.com wrote:
Hi,
Here is the code of frame()
Code:
void ViewerBase::frame(double simulationTime)
{
if (_done) return;
if (_firstFrame)
{
viewerInit();
if (!isRealized())
{
realize();
}
_firstFrame = false;
}
advance(simulationTime);
eventTraversal();
updateTraversal();
renderingTraversals();
}
It calls viewerInit() on the first frame.
Don't I need to do that myself if I expand the code?
By looking at the viewerInit() code. I think I might be able to expand
the code and init all the view I created.
Thank you!
Cheers,
Jimmy
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16447#16447
___
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
Re: [osg-users] Excluding a Geode from Small Feature Culling
Hi Per,
Great example, thanks for taking the time to post this.
Ok I created a class SmallFeatureCullExcluder (inherits NodeCallBack) and
added the code you put in the () operator. I also changed the mask to
cullingSet.setCullingMask(cullingSetMask
~osg::CullSettings::SMALL_FEATURE_CULLING);
Then I added this as a cull-callback on the Geode I want to exclude. I'm
afraid to say it didn't work, it still gets small feature culled.
Also I tried adding it on the parent (PositionAttitudeTransform) and as an
UpdateCallBack instead of CullCallBack, still no luck.
The code is being reached (I set a breakpoint) but when you zoom out enough
the object gets small-feature culled and the code is not reached.
Any ideas what I may be doing wrong?
Thank you,
Andrew
On Tue, Sep 8, 2009 at 8:07 PM, Per Fahlberg pe...@remograph.com wrote:
Hi Andrew,
I was trying to accomplish exactly the same and finally found a solution,
if you search the mailing list for Disabling small feature culling for a
subgraph you will find the email thread when I discussed this with Robert.
I've pasted the final solution below for your convinienc.
Regards
/Per
Hi,
For the record I've found a way to get things working the way I want it, by
changing the culling mask of the culling set at the back of the projection
culling stack, small feature culling can now be both enabled and disabled
for subgraphs. The code for my callback looks like this now (the code is for
enabling small feature culling, change the | to ~ to disable small
feature culling):
virtual void operator() (osg::Node *node, osg::NodeVisitor *nv)
{
osgUtil::CullVisitor *cv = dynamic_castosgUtil::CullVisitor*(nv);
if(cv){
osg::CullStack::CullingStack projCullStack =
cv-getProjectionCullingStack();
if(!projCullStack.empty()){
osg::CullingSet cullingSet = projCullStack.back();
osg::CullingSet::Mask cullingSetMask = cullingSet.getCullingMask();
cullingSet.setCullingMask(cullingSetMask |
osg::CullSettings::SMALL_FEATURE_CULLING);
traverse(node,nv);
cullingSet.setCullingMask(cullingSetMask);
}else
// Do not really now what to do if it is empty
traverse(node,nv);
}else
traverse(node,nv);
}
Andrew Thompson wrote:
Hi there, and thanks for your response,
well I am using small feature culling in my application to improve
performance. Its a CAD-style app and I have hundreds of thousands of Geodes
on the screen at any one time. Many are really small so I am throttling
small-feature culling to maintain a decent framerate when moving around.
When static the scene re-draws everything.
But - there are certain objects, markers around the scene, I'd like to
exclude from the small feature cull if possible.
If its not possible, no matter, just was hoping there was a simple
solution to this.
Thank you, Andrew
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=17154#17154
___
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
Re: [osg-users] Loading an osg::Image using setImage
Hmm, well that was easy!
The flipping of rows worked fine, to set the image I used GL_BGR for pixel
format only, keeping GL_RGB as internal pixel format (else I got a gray
square).
Thank you for an extremely helpful response :)
Andrew
On Thu, Aug 20, 2009 at 6:15 PM, Farshid Lashkari fla...@gmail.com wrote:
Hi Andrew,
It looks like the original bitmap is in BGR format, so you will probably
need to use the GL_BGR pixel format when calling setImage(). To unflip the
image it seems like you can iterate backwards over the source image inside
your copy loop:
ptrSourceRow = ptrSrcImage + ( (iHeight - 1 - i) * iStride);
I believe this should fix your problems.
Cheers,
Farshid
On Thu, Aug 20, 2009 at 9:46 AM, Andrew Thompson andyb1...@yahoo.co.ukwrote:
Hi there,
I am trying to load an osg::Image using the setImage method - inparticular
I am copying a Managed bitmap (System.Drawing.Bitmap) to the osg::Image to
use it as a texture map.
As you can see I'm having a few problems. Here's the osg::Image texture
mapped onto a quad when I load it in from file using osgDB::readImageFile
[Image:
http://i137.photobucket.com/albums/q217/andyb1979/tquadreadimage.png ]
Here's the same textured quad, but the osg::Image was created using
setImage and a copy from a managed bitmap
[Image:
http://i137.photobucket.com/albums/q217/andyb1979/th_tquadsetimage.png ]
As you can see the image seems to have been inverted and flipped!
Here is my code to convert a managed bitmap to osg::Image. The input
bitmap has been loaded from file, is in the format 24bpp RGB.
I know I'm getting the size/bits per pixel right as the output osg::Image
is the right shape and size, with no tearing. However I don't know why the
image is inverted!
Code:
osg::ref_ptrosg::Image
SceneUtil::ManagedBitmapToOSGImage(System::Drawing::Bitmap ^ bitmap)
{
//
// Check params
//
if (bitmap == nullptr)
{
throw gcnew Exception(Unable to convert
System::Drawing::Bitmap to osg::Image as the input image is null);
}
if (bitmap-PixelFormat !=
System::Drawing::Imaging::PixelFormat::Format24bppRgb)
{
throw gcnew Exception(Unable to convert
System::Drawing::Bitmap to osg::Image as the input image must be in the
format Format24bppRgb);
}
// Create a new OSG Image
osg::ref_ptrosg::Image image = new osg::Image();
System::Drawing::Imaging::BitmapData ^ bitmapData =
bitmap-LockBits(
System::Drawing::Rectangle(0, 0, bitmap-Width,
bitmap-Height),
System::Drawing::Imaging::ImageLockMode::ReadOnly,
System::Drawing::Imaging::PixelFormat::Format24bppRgb);
// Create data to hold the destination image
BYTE * ptrSrcImage = (BYTE*)bitmapData-Scan0.ToPointer();
BYTE * ptrDestImage = new unsigned char [bitmap-Width *
bitmap-Height * 3];
BYTE * ptrSourceRow = nullptr;
BYTE * ptrDestRow = nullptr;
int iWidth = bitmapData-Width;
int iHeight = bitmapData-Height;
int iStride = bitmapData-Stride;
// Copy the System::Drawing::Bitmap instance over line by line -
this gets around the
// lack of stride support in the osg::Image.
for(int i = 0; i iHeight; i++)
{
// Get the source row pointer
ptrSourceRow = ptrSrcImage + (i * iStride);
// Get the destination row pointer
ptrDestRow = ptrDestImage + (i * (iWidth * 3));
// Copy the source row to the destination row
memcpy(ptrDestRow, ptrSourceRow, iWidth * 3);
}
// Set the data on the osg::Image
image-setImage(
bitmap-Width,
bitmap-Height,
1,
GL_RGB,
GL_RGB,
GL_UNSIGNED_BYTE,
ptrDestImage,
osg::Image::USE_NEW_DELETE);
bitmap-UnlockBits(bitmapData);
return image;
}
Any ideas?
Thank you!
Andrew
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16492#16492
___
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
Re: [osg-users] transparent object sorting and back face culling
Hi Jason, Ok I've updated my code to work with each side as a geode, however this is still not giving me the results I want. Think a transparent cube, the sides have bounding spheres but at certain camera locations and orientations, the wrong sides are rendered in the wrong order. For my transparent cube object, is it possible to specify the render order in some sort of call back? So in the update pass, get the camera eye and sort the drawables myself? Thanks, Andrew On Mon, Aug 17, 2009 at 5:20 PM, Jason Daly jd...@ist.ucf.edu wrote: Andrew Thompson wrote: If I create individual QUAD's will this work better? Or perhaps does it have to be individual Geodes to get the sorting working right? It's per-geode, I believe --J ___ 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
Re: [osg-users] Visual Studio 2005
Oh you need to setup the environment variables to tell Windows where to look for the files. Here, follow this guide: http://www.macs.hw.ac.uk/modules/F24VS2/Labs/OpenSceneGraphTutorial.pdf Cheers, Andrew On Sun, Aug 16, 2009 at 8:52 PM, Michael W. Hall hal...@att.net wrote: Finally found it. I am having trouble compiling it. I keep getting osg/Geode does not exist. It is in C:\Program Files\OpenSceneGraph\include\osg. What could be wrong? I have changed the project and told the project file where my osg is installed. Michael On Sat, 2009-08-15 at 12:07 +0100, Andrew Burnett-Thompson wrote: It's here: http://www.april1985.com/2008/02/19/osgnetdemo/ under osgDotNetDemo.rar http://www.april1985.com/?dl_id=7 Hope that helps, Andrew On Sat, Aug 15, 2009 at 4:46 AM, Michael W. Hall hal...@att.net wrote: I for the life of me cannot find the demo. Can you send it to me off of the list? Thanks, Michael On Wed, 2009-08-12 at 14:55 +0100, Andrew Burnett-Thompson wrote: Hi there, there's a great demo covering integration of OpenSceneGraph with C++/CLI discussed here: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-February/007430.html http://www.april1985.com/2008/02/19/osgnetdemo/ I'm using this successfully in a C# / OpenSceneGraph app by keeping all my OSG workings in C++ and the UI in C# with C++/CLI as a bridge between the two. Fast and performant, relatively trouble free. Not a bad way to work with OSG! Hope this helps, Andrew On Wed, Aug 12, 2009 at 2:51 PM, Michael W. Hall hal...@att.net wrote: I am just trying to create a project. What type of project is the best to start with. I chose the C++/CLR application. I got just a blank form and I have added a status bar to it and a menu bar with the designer. I am now trying to figure out how to create a window on the form to render the scene. That is where I am stuck. Have not done any 3D with windows/VS 2005 and was looking for a little help to get going. Michael On Tue, 2009-08-04 at 21:48 -0600, Chris 'Xenon' Hanson wrote: Michael W. Hall wrote: Since I am having issues with my linux box, I am tinkering with OSG in Visual Studio 2005. I am not having much luck. I was wondering if anyone can point me to some good example code for VS 2005. Clarify what you're trying to do, and what you're having problems with exactly? I use OSG with VC++ 2005 every day. I am wanting to do C++/CLR. Well, that is a different can of worms. I can't help you much there, but you should be able to get the regular C++ portion of OSG working without problems and then build on that to do your CLR stuff. ___ 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 ___ 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
Re: [osg-users] Visual Studio 2005
It's here: http://www.april1985.com/2008/02/19/osgnetdemo/ under osgDotNetDemo.rar http://www.april1985.com/?dl_id=7 Hope that helps, Andrew On Sat, Aug 15, 2009 at 4:46 AM, Michael W. Hall hal...@att.net wrote: I for the life of me cannot find the demo. Can you send it to me off of the list? Thanks, Michael On Wed, 2009-08-12 at 14:55 +0100, Andrew Burnett-Thompson wrote: Hi there, there's a great demo covering integration of OpenSceneGraph with C++/CLI discussed here: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-February/007430.html http://www.april1985.com/2008/02/19/osgnetdemo/ I'm using this successfully in a C# / OpenSceneGraph app by keeping all my OSG workings in C++ and the UI in C# with C++/CLI as a bridge between the two. Fast and performant, relatively trouble free. Not a bad way to work with OSG! Hope this helps, Andrew On Wed, Aug 12, 2009 at 2:51 PM, Michael W. Hall hal...@att.net wrote: I am just trying to create a project. What type of project is the best to start with. I chose the C++/CLR application. I got just a blank form and I have added a status bar to it and a menu bar with the designer. I am now trying to figure out how to create a window on the form to render the scene. That is where I am stuck. Have not done any 3D with windows/VS 2005 and was looking for a little help to get going. Michael On Tue, 2009-08-04 at 21:48 -0600, Chris 'Xenon' Hanson wrote: Michael W. Hall wrote: Since I am having issues with my linux box, I am tinkering with OSG in Visual Studio 2005. I am not having much luck. I was wondering if anyone can point me to some good example code for VS 2005. Clarify what you're trying to do, and what you're having problems with exactly? I use OSG with VC++ 2005 every day. I am wanting to do C++/CLR. Well, that is a different can of worms. I can't help you much there, but you should be able to get the regular C++ portion of OSG working without problems and then build on that to do your CLR stuff. ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with lighting when scaled
Yes here's the code, I had this problem myself recently [code] // The following is taken from the osg::StateSet documentation re: GL_NORMALIZE / * If the transformation matrix scales the subgraph then the normals * of the underlying geometry will need to be renormalized to be unit * vectors once more. This can be done transparently through OpenGL's * use of either GL_NORMALIZE and GL_RESCALE_NORMAL modes. * * To enable it in the OSG, you simply need to attach a local osg::StateSet * to the osg::Transform, and set the appropriate mode to * ON via stateSet-setMode(GL_NORMALIZE, osg::StateAttribute::ON); / // Create a scene stateset osg::ref_ptrosg::StateSet sceneState = sceneRoot-getOrCreateStateSet(); // Set the SceneRoot to normalise normals when scaling is applied to objects. sceneState-setMode(GL_NORMALIZE, osg::StateAttribute::ON); [/code] On Fri, Aug 14, 2009 at 3:11 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi David, I scale the PositionAttitudeTransform by (5,5,5) for example, because my model is too small, but then the lighting isnt sufficient. Is there a way to scale the lighting as well ? Or how can I keep the light constant with scaling the model ? This is an FAQ. Set GL_RESCALE_NORMAL or GL_NORMALIZE on your node, because the transform is scaling the normals used for lighting too. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.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
Re: [osg-users] Visual Studio 2005
Hi there, there's a great demo covering integration of OpenSceneGraph with C++/CLI discussed here: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-February/007430.html http://www.april1985.com/2008/02/19/osgnetdemo/ I'm using this successfully in a C# / OpenSceneGraph app by keeping all my OSG workings in C++ and the UI in C# with C++/CLI as a bridge between the two. Fast and performant, relatively trouble free. Not a bad way to work with OSG! Hope this helps, Andrew On Wed, Aug 12, 2009 at 2:51 PM, Michael W. Hall hal...@att.net wrote: I am just trying to create a project. What type of project is the best to start with. I chose the C++/CLR application. I got just a blank form and I have added a status bar to it and a menu bar with the designer. I am now trying to figure out how to create a window on the form to render the scene. That is where I am stuck. Have not done any 3D with windows/VS 2005 and was looking for a little help to get going. Michael On Tue, 2009-08-04 at 21:48 -0600, Chris 'Xenon' Hanson wrote: Michael W. Hall wrote: Since I am having issues with my linux box, I am tinkering with OSG in Visual Studio 2005. I am not having much luck. I was wondering if anyone can point me to some good example code for VS 2005. Clarify what you're trying to do, and what you're having problems with exactly? I use OSG with VC++ 2005 every day. I am wanting to do C++/CLR. Well, that is a different can of worms. I can't help you much there, but you should be able to get the regular C++ portion of OSG working without problems and then build on that to do your CLR stuff. ___ 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
Re: [osg-users] [HELP] Cull time in stats?
Hi there, Sorry to interrupt, I have a similar issue with a flat scene graph and it's on my Todo list to remove position attitude transforms and flatten them onto the Geodes. My application is a CAD style application, with a scene graph that consists of 300,000 objects, each object is 1x PAT, 1x Geode and 1x Geometry, each Geometry is about 100 vertices (average) and multiple primitives. Each Object is wrapped in a class I have defined that contains the OSG nodes. The PAT's are used to position the objects, however I only actually need them when updating an objects position via picking/manipulating and also in-code manipulation. I was thinking to store the position/attitude/scale in my wrapper class and when they are updated, get the geometry vertices, inverse transform them with the old matrixtransform, and forward transform them with a new matrix transform. Does this sound like a feasible way of removing the Pats? Thank you, Andrew On Tue, Aug 11, 2009 at 1:29 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Jimmy, Regarding of having a flat scene graph. Does it matter if the whole scene will always be seen? Would it still improve the performance if I balance the scene graph more? In the case where the whole scene will always be seen (think about it carefully, though, because I think these cases should be rare in practice) then balancing the graph will not help, but removing groups and transforms will. That is to say, if all your objects will always be visible, then in order to reduce the cull time you need to reduce the number of objects to traverse to get to the geometry. To reduce the draw time, you need to group geometry so that data is uploaded to the card in good-sized chunks. So for example, if two objects will always be in the same position relative to one another, place both in the same osg::Geometry, transforming the vertices of the second one to be where the transform would have placed it relative to the first. Say object 0 has vertex array V0 and object 1 has vertex array V1, and suppose that object 0 is at world position T0 and object 1 is at position T1, then you can build a vertex array V2 containing the vertices of both objects like this: V2 = (V0, V1 + (T1 - T0)) (suppose the addition above will apply the same translation to all vertices in V1) and then position the composite object at position T0. You can extend this if you have groups of many objects that will always be in the same relative position from each other, of course. For example if a city has buildings and all the buildings are static in world space, then place them all in the world coordinate frame with no transforms or groups. They can still be in different geometry objects if they have a sufficient number of vertices (thousands). If not, then group several of them in the same geometry object and use a texture atlas to texture them all with the same texture file. Similar scene graph optimization tips have been discussed in the past on the list. The archives should contain even more tips. I don't know if there is a wiki page on openscenegraph.org that collects such tips, but if there isn't we should create one... Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.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
Re: [osg-users] line intersection performance
This is an old thread I found when I was searching. It may not be in the forums so I have included the original text below as a quote. I am trying to implement something like this, in order to compute hit tests on a line. I don't need to know which objects intersected the line, or get a list of objects/intersections out, just need to know Is there an intersection or not. The original posts are included below. Would anyone know how I might go about implementing this? /// A couple of other questions related to intersection performance: ... 2) I need to do line-of-sight tests where I am only interested in whether any intersection exists, and not what those intersections are. This allows for a trap door optimization where the search process terminates on the first positive intersection. Is there a way to do that with the current osgUtil::IntersectionVisitor, or do I need to modify it to serve this purpose? Thanks, Peter Hi Jean-Sébastien, Jean-Sébastien Guay wrote: So the answer IMHO would be that in any case, you will want to try and build a good scene graph (both for culling performance and intersection performance). Whether you want to make a global kd-tree for the whole scene will depend on how dynamic your scene is, and if you can take the time to implement it so that only parts that change need updating. In my case I am reading OpenFlight files produced by a third party, so I don't have much control over whether it was constructed efficiently or not. Since the terrain will be static, my thought was to build a mostly static KdTree of scene graph nodes separate from the normal rendering state graph and to be used for culling and intersection tests. I believe a number of other 3D engines use this approach. However my question was really whether something like this already existed in OSG, to which the answer is no. This is not implemented currently. It's another one of those little projects I'd like to do eventually. It's what some publications call test-intersection vs find-intersection. Test-intersection: If all you want to know is if something intersects (for example, for shadow tests in raytracing) some shortcuts can be taken. Find-intersection: If you really want to find all objects that intersect (and potentially then sort by distance so you can get the closest one) (for example, for the main rays in raytracing) then you'd do it more or less the way it's done right now. If you want to implement test-intersection, you could subclass IntersectionVisitor/LineSegmentIntersector, or you could do it directly in these classes as an option and then submit it to OSG. :-) I do need this feature, so I will look into implementing it in osgUtil::IntersectionVisitor. This should be as simple as setting a flag, I think, and modifying the traversal to return as soon as an intersection is found. I will let the list know how it goes. Thanks, Peter /// ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Perspective / Orthogonal projection matrix with CameraManipulator
Hi Robert, Thanks for your helpful reply. I've sorted this problem by taking the following steps 1. Removal of camera manipulators from the scene (I had a custom manipulator that allowed you to set target/position, but event handling was done elsewhere in my external application) 2. Creation of a class CCameraView which does little more than hold variables to setup the camera, such as position, target, field of view, near/far, isOrthogonal, orthogonal zoom factor etc 3. Multiple instances of my CCameraView class are held by the application, one for the perspective freelook view, one for a plan view, plus others for various views around the scene that I need. These are updated appropriately by my applications event processing code. 4. Setting of the current active CCameraView on the scene as appropriate (depending on what mode the app is in) 5. Within the render loop, immediately prior to Viewer-Frame, call Viewer-getCamera() to get the main camera, and pass it to the current CameraView instance (a method called UpdateCameraMatrices). This then applies the desired view/projection matrix 6. Render the scene Simple really when you know how. I realise the above is not an OSG problem, more a How to use OSG in my system in such a way problem, but I am posting as others may find the solution useful. Thank you, Andrew On Wed, Aug 5, 2009 at 10:00 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Andrew, On Wed, Aug 5, 2009 at 9:35 AM, Andrew Burnett-Thompsonaburnettthomp...@googlemail.com wrote: I noticed osg::Camera offers more direct access to the view/projection than the camera manipulator (which only affects the View), so I've dumped camera manipulator and created two cameras - perspective / plan. Yes this would be doable, although having two separate views in CompositeViewer might be more logical an easier to manage. Then I am directly updating the camera in the perspective/plan mode from my own event handling code. (In addition I need multiple other cameras that I can position around the scene in perspective mode and switch to on various key presses). One problem - I am trying to swap the cameras in/out of the osg::Viewer so I was using osg::Viewer::setCamera and getCamera to get/set the default camera, however it is not behaving as expected. What problem are you seeing? Using the viewer.getCamera()-set..MatrixAs..(..) methods work fine, but if you need to make sure that you aren't also attaching a CameraManipulator as this will overwrite your values on each frame. Is this the right way to set the default camera? Just use the Camera that is already assigned to the Viewer. Robert. ___ 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
Re: [osg-users] Perspective / Orthogonal projection matrix with CameraManipulator
Oh and for reference (forgot to add)
the method to update the camera is as follows
/
void CCameraView::UpdateCameraMatrices(osg::Camera * camera)
{
// Set the projection matrix on the camera
if (this-m_bIsOrthogonal)
{
camera-setProjectionMatrixAsOrtho(-m_fOrthoZoom, m_fOrthoZoom,
-m_fOrthoZoom, m_fOrthoZoom, m_fNearClip, m_fFarClip);
}
else
{
camera-setProjectionMatrixAsPerspective(m_fFieldOfView, m_fAspect,
m_fNearClip, m_fFarClip);
}
// Set the view matrix on the camera
camera-setViewMatrixAsLookAt(GetCameraPosition(), GetCameraTarget(),
GetUpVector());
}
/
On Fri, Aug 7, 2009 at 11:49 AM, Andrew Burnett-Thompson
aburnettthomp...@googlemail.com wrote:
Hi Robert,
Thanks for your helpful reply. I've sorted this problem by taking the
following steps
1. Removal of camera manipulators from the scene (I had a custom
manipulator that allowed you to set target/position, but event handling was
done elsewhere in my external application)
2. Creation of a class CCameraView which does little more than hold
variables to setup the camera, such as position, target, field of view,
near/far, isOrthogonal, orthogonal zoom factor etc
3. Multiple instances of my CCameraView class are held by the application,
one for the perspective freelook view, one for a plan view, plus others for
various views around the scene that I need. These are updated appropriately
by my applications event processing code.
4. Setting of the current active CCameraView on the scene as appropriate
(depending on what mode the app is in)
5. Within the render loop, immediately prior to Viewer-Frame, call
Viewer-getCamera() to get the main camera, and pass it to the current
CameraView instance (a method called UpdateCameraMatrices). This then
applies the desired view/projection matrix
6. Render the scene
Simple really when you know how. I realise the above is not an OSG problem,
more a How to use OSG in my system in such a way problem, but I am posting
as others may find the solution useful.
Thank you,
Andrew
On Wed, Aug 5, 2009 at 10:00 AM, Robert Osfield
robert.osfi...@gmail.comwrote:
Hi Andrew,
On Wed, Aug 5, 2009 at 9:35 AM, Andrew
Burnett-Thompsonaburnettthomp...@googlemail.com wrote:
I noticed osg::Camera offers more direct access to the view/projection
than
the camera manipulator (which only affects the View), so I've dumped
camera
manipulator and created two cameras - perspective / plan.
Yes this would be doable, although having two separate views in
CompositeViewer might be more logical an easier to manage.
Then I am directly updating the camera in the perspective/plan mode from
my
own event handling code. (In addition I need multiple other cameras that
I
can position around the scene in perspective mode and switch to on
various
key presses).
One problem - I am trying to swap the cameras in/out of the osg::Viewer
so I
was using osg::Viewer::setCamera and getCamera to get/set the default
camera, however it is not behaving as expected.
What problem are you seeing? Using the
viewer.getCamera()-set..MatrixAs..(..) methods work fine, but if you
need to make sure that you aren't also attaching a CameraManipulator
as this will overwrite your values on each frame.
Is this the right way to set the default camera?
Just use the Camera that is already assigned to the Viewer.
Robert.
___
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
Re: [osg-users] Perspective / Orthogonal projection matrix with CameraManipulator
Hi Robert, Thanks for your reply. Yes I realise the problems inherent in making an orthogonal view behave like a perspective view. What I'm trying to do however is create a plan view on a CAD like application for oil rigs. So imagine in perspective view you can move around the rig, in plan view you want to see it top down, everything's in wireframe, sort of like a blueprint. I need the ability to zoom in the plan view, but not rotate or move forwards/backwards, literally just pan/zoom. I noticed osg::Camera offers more direct access to the view/projection than the camera manipulator (which only affects the View), so I've dumped camera manipulator and created two cameras - perspective / plan. Then I am directly updating the camera in the perspective/plan mode from my own event handling code. (In addition I need multiple other cameras that I can position around the scene in perspective mode and switch to on various key presses). One problem - I am trying to swap the cameras in/out of the osg::Viewer so I was using osg::Viewer::setCamera and getCamera to get/set the default camera, however it is not behaving as expected. Is this the right way to set the default camera? I just one one to render at a time, not to composite the view. If I sort the orthogonal code (Plan view) I'll post it here for reference purposes. Thank you, Andrew On Wed, Aug 5, 2009 at 8:23 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Andrew, I would not recommend trying to make an orthographic view behave like a perspective view, it simple doesn't work (this is not an OSG issue, but the basic principles involved.) I've written about this before so I won't waste my key presses have a look through the archives. The upshot is I would suggest keeping orthographic views for fixed maps/side/front views, or very constrained user interaction models. If you try to make a orthographic behave like a perspective you'll just waste lots of time. Robert. On Thu, Jul 30, 2009 at 6:22 PM, Andrew Thompsonandyb1...@yahoo.co.uk wrote: Hi there, I am using a custom CameraManipulator class (inheriting osgGA::MatrixManipulator) which is added to my scene after the OpenSceneGraph is initialised The CameraManipulator has two member variables I've added, a Vec3d target and position. These are used to create a projection matrix by calling Matrix::makeLookAt. As the events are handled by the manipulator, I am updating the position/target and recomputing the matrix, then on Frame I am returning the constructed matrix. This provides a great perspective view, however I cannot work out how to construct an orthogonal projection using a target/position. In addition, I'd like to be able to change the Field Of View when I create the matrix. I realise there is a Matrix::makeOrtho and Matrix::makePerspective, however I'm not sure how to use these with my CameraLocation/Target variables. Could anyone offer me some advice? Thank you! Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15659#15659 ___ 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
Re: [osg-users] OSG and WPF Questions
Hi Martin,
From memory (I've worked with WPF before), each WPF control has at its root
an HWND handle, which is what the osgDotNet demo uses to bind the open scene
graph to the Windows forms control.
So I think if you substitute the HWND handle with the WPF HWND the osgDotNet
stuff should work.
Here - I'm using this (but Windows Forms) to initialise an OpenSceneGraph on
a WinForms user control (which is probably very similar to the osgDotNet
demo)
Try googling WPF HWND Interop and see what you come up with. Apologies if
you have already tried this.
Also I don't know how to stop the other window appearing - that sounds like
an OSG problem and I'm no expert in OSG!!
Cheers,
Andrew
/
void RenderSurfaceView::InitOSG()
{
RECT rect;
// Get the UserControl's Win32 handle
HWND mHwnd=(HWND)this-Handle.ToInt32();
// Get the client area
GetWindowRect(mHwnd, rect);
// Create a WindowData struct from the Win32 Handle
// WindowData is used to pass in the Win32 window handle attached
the GraphicsContext::Traits structure
osg::ref_ptrosg::Referenced windata = new
osgViewer::GraphicsWindowWin32::WindowData(mHwnd);
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
// Now setup the GraphicsContext::Traits by setting width, height, x
position, y position etc...
traits-x = 0;
traits-y = 0;
traits-width = rect.right - rect.left;
traits-height = rect.bottom - rect.top;
traits-windowDecoration = false;
traits-doubleBuffer = true;
traits-sharedContext = 0;
traits-inheritedWindowData = windata;
// We must set the pixelformat before we can create the OSG
Rendering Surface
PIXELFORMATDESCRIPTOR pixelFormat =
{
sizeof(PIXELFORMATDESCRIPTOR),
1,
PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL|PFD_DOUBLEBUFFER,
PFD_TYPE_RGBA,
32,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0,
24,
0,
0,
PFD_MAIN_PLANE,
0,
0, 0, 0
};
// Get the device context for the Win32 handle to the control
HDC hdc = ::GetDC(mHwnd);
if (hdc==0)
{
::DestroyWindow(mHwnd);
return ;
}
// Set the pixel format on the device context
int pixelFormatIndex = ::ChoosePixelFormat(hdc, pixelFormat);
if (pixelFormatIndex==0)
{
::ReleaseDC(mHwnd, hdc);
::DestroyWindow(mHwnd);
return ;
}
if (!::SetPixelFormat(hdc, pixelFormatIndex, pixelFormat))
{
::ReleaseDC(mHwnd, hdc);
::DestroyWindow(mHwnd);
return ;
}
// Create an Open Scene Graph graphics context
osg::ref_ptrosg::GraphicsContext gc =
osg::GraphicsContext::createGraphicsContext(traits);
// Create an Open Scene Graph camera
this-camera = new osg::Camera;
osg::CullSettings::CullingMode cullMode =
osg::CullSettings::ENABLE_ALL_CULLING;
// Force all culling on
camera-setCullingMode(cullMode);
// Set the graphics context on the camera and the viewport
camera-setGraphicsContext(gc);
camera-setViewport(new
osg::Viewport(0,0,traits-width,traits-height));
camera-setDrawBuffer(GL_BACK);
camera-setReadBuffer(GL_BACK);
// Finally, create an osgViewer instance and add the camera to it
this-osgViewer = new osgViewer::Viewer();
osgViewer-getCamera()-setClearColor(osg::Vec4(0.8,0.8,0.8,1));
osgViewer-addSlave(camera);
// ..
// Run the Open Scene Graph thread
RunOSG();
// And set the Is Initialised flag
this-osgInitialised = true;
}
/
On Wed, Jul 29, 2009 at 1:50 PM, Martin Fleck eladamri...@hotmail.comwrote:
Hi,
seems like the 5 posts above should be in a new topic ^^;
Addition to my post: I got the osgNETDemo running, but still its
WindowsForms and not WPF, so I'd still be happy about any advise /help
someone could give me :)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=15594#15594
___
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] Specular Highlight with Vertex Colors?
Hi all, I'm using vertex colors on my models to save on memory in a CAD-style application, as one color per geometry is more than sufficient for my needs. However, is it possible to have specular highlights when using vertex colors? For instance, I'm adding a color as follows /// osg::Geometry * coneBodyGeometry = new osg::Geometry(); ... // Set the Colour to the entire object osg::ref_ptrosg::Vec4Array colourArray = new osg::Vec4Array(); colourArray-push_back(osg::Vec4(1.0f, 0.5f, 0.5f, 1.0f)); coneBodyGeometry-setColorArray(colourArray.get()); coneBodyGeometry-setColorBinding(osg::Geometry::BIND_OVERALL); /// However so far I can see the only way to add specular is via a StateSet. I previously had one stateset per object, but this consumed too much memory, so now have a shared stateset /// sharedState = new osg::StateSet(); // Create a material osg::ref_ptrosg::Material mat = new osg::Material(); // Set specular attribute mat-setDiffuse(osg::Material::Face::FRONT_AND_BACK, osg::Vec4(0,0,0,0)); mat-setSpecular(osg::Material::FRONT, osg::Vec4f(1.0f, 1.0f, 1.0f, 1.0f)); mat-setShininess(osg::Material::FRONT, 12.0f); mat-setColorMode(osg::Material::ColorMode::SPECULAR); sharedState-setAttribute(mat.get(), osg::StateAttribute::Values::ON); sharedState-setMode(GL_COLOR_MATERIAL, osg::StateAttribute::ON); /// Of course, the material then mixes its color with the vertex color, despite the fact that its transparent. Does anyone know a way to have specular on objects but either sharing stateset, or without a stateset? Thanks, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Specular Highlight with Vertex Colors?
Thanks for your reply Jason, I actually worked this out I think, I removed mat-setDiffuse and added mat-setColorMode(osg::Material::ColorMode::DIFFUSE) and it seemed to do the trick! Not sure why, but hey, it works. I now have a shared stateset with various attributes like specular/backface culling etc... and vertex colors on the objects themselves :) On Fri, Jul 17, 2009 at 6:50 PM, Jason Daly jd...@ist.ucf.edu wrote: Hi, Andrew, Andrew Burnett-Thompson wrote: // Set specular attribute mat-setDiffuse(osg::Material::Face::FRONT_AND_BACK, osg::Vec4(0,0,0,0)); mat-setSpecular(osg::Material::FRONT, osg::Vec4f(1.0f, 1.0f, 1.0f, 1.0f)); mat-setShininess(osg::Material::FRONT, 12.0f); mat-setColorMode(osg::Material::ColorMode::SPECULAR); sharedState-setAttribute(mat.get(), osg::StateAttribute::Values::ON); sharedState-setMode(GL_COLOR_MATERIAL, osg::StateAttribute::ON); /// Of course, the material then mixes its color with the vertex color, despite the fact that its transparent. Try adding this to your global StateSet: osg::LightModel *lm =new osg::LightModel(); lm-setColorControl(osg::LightModel::SEPARATE_SPECULAR_COLOR); stateset-setAttributeAndModes(lm, osg::StateAttribute::ON); I'm not sure if it'll work, but it's all I can think of... --J ___ 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
Re: [osg-users] Specular Highlight with Vertex Colors?
Yes I was originally adding material plus disabling back-face culling per stateset per Geode, hence the huge saving. Moving the colour to the vertices (one colour bound overall) does the same job as far as I'm concerned and definitely saves on memory/performance :) I'm still having a lot of issues with memory - probably due to the way I've constructed my scenegraph - I will elaborate next week on the other thread you quoted. Thanks, Andrew On Fri, Jul 17, 2009 at 7:07 PM, Thrall, Bryan bryan.thr...@flightsafety.com wrote: Andrew Burnett-Thompson wrote on Friday, July 17, 2009 10:42 AM: However so far I can see the only way to add specular is via a StateSet. I previously had one stateset per object, but this consumed too much memory, so now have a shared stateset I assume you're referring to your statement here: http://forum.openscenegraph.org/viewtopic.php?t=3121 Where you say moving from a StateSet per Geode to a shared StateSet saved you 250MB. We don't have any details on how you're creating those StateSets, but the StateSet itself is only about 192 bytes, so the rest of the memory savings probably come from all the StateAttributes you must be adding to the StateSets. Perhaps if you shared the StateAttributes as much as possible, you could still use a StateSet per Geode (such as for adding specular) with a much smaller memory footprint (closer to 36MB for your 20 object model). I'm assuming a lot about what you were doing, though, so feel free to shoot me down if some of my assumptions are wrong :) -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ 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
Re: [osg-users] Rendering Performance and Proper Way to have millions of moveable objects
Ok, I'm going to have a look into occluders later, the rendering speed seems to have significantly improved given the use of small feature culling (pixel size is throttled as you move around the scene to maintain an interactive framerate). My next big issue is memory usage. I am finding the OSG app as it stands is using approximately 50% more memory than a legacy app we are replacing, which is just coded in standard OpenGL. Objects are imported in a legacy file format, which have previously been created in a CAD package. The object format is not optimal but can be optimised once loaded. For each object in the scene (of which there may be up to 1.5m objects), I am creating the following OSG constructs: 1. 1x PositionAttitudeTransform 2. 1x Geode (parent is PAT) 3. 1x Stateset per Geode containing material data (objects are a single colour, no textures). 4. 1x Geometry (added to Geode) - 1x Vec3Array containing vertices - N PrimitiveSets as Currently osg::DrawArrays(POLYGON) - Smoothing visitor is run over the geometry to create Normals Now we have 1 Geometry per Geode, which may or may not be efficient. The Geometry is defined as our Object. Each object in the scene is pickable and movable so if it is more efficient to group multiple Geometry's per Geode then I need a way to move these around using pick/translate/rotate/scale. Secondly the use of DrawArrays(POLYGON) results in a horrendous amount of primitivesets, however I am subsequently running the osgUtil::Optimizer over the geometry to clean it up - which does a great job. So far I've experimented with MERGE_GEOMETRY and TRI_STRIPS of which MERGE seems to give the same memory results but is much quicker to run. TRISTRIPS appears to drop the number of vertices requred per object by about 60% but curiously in task manager memory doesn't drop. I am considering the following options to reduce memory overhead. 1. Get rid of PATs. Instead store position/attitude/scale as Vec3f in our object (PAT uses Vec3d) and compute a matrix transform on creation of the object. When an object is picked, insert a PAT above it in the tree and move it around, after remove the PAT and flatten the transform onto the vertices - I guess I have to do a forward/reverse transform on the vertices to go from global to local space and vice versa for this? 2. Group multiple geometries per geode. Not keen on this but if it will help I'll work around it. 3. Experiment more with osgUtil::Optimizer flags to reduce vertex count. 4. When loading the legacy file format, import object by object, use osgUtil::Simplifier to create medium/low detail versions, serialize all three into our custom file format and use PagedLODs for each object. Then for performance 5. Tile the database, grouping objects by location to assist the cull phase 6. Removal of PATs as per 1. should help the cull phase 7. Look into the use of shadow occlusion to remove objects. Please let me know what you think - any feedback is much appreciated, Andrew -- Off topic - I replied to osg-users@lists.openscenegraph.org with the subject line Re: Rendering Performance and Proper Way to have millions of moveable objects so I hope this has now gone to the right thread. If I'm still doing something wrong fee free to let me know. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering Performance and Proper Way to have millions of moveable objects
Ok I quickly tried that, setting setUseDisplayList and setSupportsDisplayList to false, and it made no noticeable difference to memory consumption. I'm calling: /// osg::ref_ptrosg::Geometry meshBodyGeometry = ... ... meshBodyGeometry-setUseDisplayList(false); meshBodyGeometry-setSupportsDisplayList(false); ... this-geode-addDrawable(meshBodyGeometry); /// The legacy app didn't use display lists either, it was quite crude. For each object to be rendered, it stored an array of vertices, normals and faces (indices to vertex array) and literally called /// glBegin(GL_POLYGON) glNormal3fv( ... ) glVertex3f( ... ) elEnd() /// So not the best way to render objects! However I'm thinking that the old code is a lot more lightweight since they are storing and rendering their vertices direct, whereas I have PAT, Geode, Geometry, PrimitiveSets Hence the questions on what steps I could take to reduce mem consumption. Thanks for your time, Andrew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering Performance and Proper Way to have millions of moveable objects
Hi Ulrich, Thanks for that, I commented out the creation of stateset for each Geode. This resulted in an incredible 250MBytes of saved memory - this is for a model with only 200,000 renderable objects as well so I guess Stateset is using (or causing to be used) ~1kb/object? Our app still uses more memory than the legacy app to load the same scene (1.050GB vs 800MB) but the gap is closing. Hey before I started optmising it was 1.8GB vs 800MB! I will definitely be looking into colouring the objects using shared statesets - or just setting a colour array to the whole primitiveset. Thanks, Andrew Now the only problem - everything's grey! But I am thinking to use the On Wed, Jul 15, 2009 at 4:20 PM, Ulrich Hertlein u.hertl...@sandbox.dewrote: Hi Andrew, On 15/7/09 2:29 PM, Andrew Burnett-Thompson wrote: My next big issue is memory usage. I am finding the OSG app as it stands is using approximately 50% more memory than a legacy app we are replacing, which is just coded in standard OpenGL. ... For each object in the scene (of which there may be up to 1.5m objects), I am creating the following OSG constructs: ... 3. 1x Stateset per Geode containing material data (objects are a single colour, no textures). If you're only dealing with a handful of colours then you could also share the StateSets. This will reduce the memory footprint *and* improve performance since the state handling code can quickly group all geometries using a common StateSet together. You mentioned that this is a CAD-style application, so maybe that makes sense in this case? Simplest case: one StateSet for red geomtry, one for green, one for blue; or maybe by type? Cheers, /ulrich ___ 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] Rendering Performance and Proper Way to have millions of moveable objects
Right I played around with small feature culling and this really gave a massive performance boost when rendering. As I mentioned I only need low detail while moving around (as its a CAD-like app) and a high detail redraw when still. So swapping out the small feature culling pixel size when moving enables smooth update rates while the user is navigating. The code is below (Trivial for you guys but I've included it for archive purposes) /// osg::CullSettings::CullingMode cullMode = osg::CullSettings::CullingModeValues::ENABLE_ALL_CULLING; // Force all culling on camera-setCullingMode(cullMode); // Set the culling pixel size float cullPixelSize = isMoving ? 20.0f : 2.0f; camera-setSmallFeatureCullingPixelSize(20.0F); /// Occlusion culling still making no difference, although I am working through the osgoccluder example. Also I'm interested in creating PagedLOD's and found the osgUtil::Simplifier class, which seems to take a long while to run, but generates a lower polygon count mesh for LODs Great stuff :) ... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rendering Performance and Proper Way to have millions of moveable objects
It is exactly that - like a CAD application. Today I had fun with osgUtil::Optimizer which reduced my vertex count by around 50% when applying MERGE_GEOMETRY. Yes I will take a look at occlusion culling. I enabled it but it made no difference. Possibly due to my flat scenegraph? Imposter's i've not heard of, thanks for the heads up :) Andrew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rendering Performance and Proper Way to have millions of moveable objects
Hi Robert, Thanks for your reply. Yes I did guess that I'm using the scene graph wrong. Fortunately with regard to our scene, while we have a lot of objects, the detail is not significant. The application allows users to simulate certain conditions that would occur in an industrial plant. So long as the model is a crude reflection of the plant it works, so we are already significantly optimising geometry. Rendering is only required as the user moves around the plant, or if an object is manipulated. During render we are currently hiding the smallest 50% of objects, which works remarkably well to improve usability (A full re-draw is performed when the user stops moving), but still the frame rate drops below interactive levels depending on how many objects remain. With regard to flattening of static transforms - how exactly would we do this? I was thinking to put a PAT as parent of a geode only while the user is picking/manipulating it, then remove it after, somehow matrix-multiplying the transform with vertices to get the new position. Is this possible? With regard to LOD's - sounds like a good plan but I think this may end up using more memory (which is an issue) even though it improves rendering performance. Paging does interest me though. I already set the cull settings to ENABLE_ALL_CULLING. I noticed that shadow occlusion (which I believe means when a large object occludes the camera, objects behind it are culled?) seems to have no effect. Is this due to my flat scene graph? View frustrum culling seems to have the largest effect. With regard to efficiently managing the scene graph (having a balanced tree), thanks for confirming that. I did have a hunch that would be the case but its nice to know. With regard to state sharing - is it possible to have one state object on multiple geodes? Or did you mean have multiple statesets with similar states? Cheers for the feedback much appreciated, Andrew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgDotNet
Hi there, Not sure if I've done this right, this is intended to be a response to the message osgDotNet here : http://groups.google.com/group/osg-users/browse_thread/thread/c8c8422c8f74b865?hl=en Anyways - assuming it is right ... I am currently writing an application using OpenSceneGraph integrated to C# .NET. Rather than use osgDotNet (which I couldn't get to compile for the latest version 2.8.0) I opted to use C++/CLI - which is Microsoft's second version of managed C++. C++/CLI is amazing, they really got it right. You can compile managed C++ classes with native member variables and functions. You can compile native classes with managed member variables and functions. You can allocate memory on the native or managed heap, you can really do what you like. A simple example of integrating osg to a .NET user control via C++/CLI can be found here: http://www.april1985.com/2008/02/19/osgnetdemo/ Once you've done that you do all your OSG work in a C++ dll with managed extensions enabled and expose the bits you want to C# via your managed C++/CLI classes. We've not opted to wrap openscenegraph, that would be far too much effort. Instead the functionality we required to expose to C# (which is minimal) is wrapped. hope this helps ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rendering Performance and Proper Way to have millions of moveable objects
Hi there, I am developing an application using OpenSceneGraph, which is essentially a visualisation tool for industrial plants. Part of the remit is to be able to load in scenes with literally millions of objects. The application loads objects from a proprietary format, so what I get is a list of objects to draw. Objects can be a number of primitive types, which include Cylinders, Cones, Spheres, Cubes and Tori, as well as Polyface Meshes. All of the primitive types (Except meshes) are constructed from a number of parameters upon load, for instance, cones have start/end radius and length. Each object must be selectable and movable in this application, so the user has full control over position, attutude, scaling as well as custom properties of the primitive (if any). In order to do this I have a prototype that calculates the vertices/primitives say for a cylinder on load, stores it in a Geode as osg::DrawArrays. Then to position the cylinder, I put this as a child to a osg::PositionAttitudeTransform with the appropriate position, rotation and scale. As a result I end up with a very flat scenegraph with a lot of PAT's at the first level and Geodes at the second level. When I render my scene the framerate drops to about 5FPS (for 50,000 cylinders) when all are in view. At 300,000 cylinders, well its pretty much dead! (Note: Hardware is ATI 3850, 512MB RAM Intel Core 2 Duo) Now a little digging and I find that PAT's essentially compute 4x matrix multiplies per object visible per frame, so these are obviously not designed to be used in this way (one per object). So my question is: -- Exactly how do you draw a really large scene containing hundreds of thousands, or even millions of primitives, but allow the user to pick/select/move the individual objects without having 1x PAT per Geode? -- I was thinking of the solution to not have PAT's and position the primitive vertices in global space, then when the user wishes to move them, attach a PAT as the parent, do the move, and detach the PAT. This would require performing a matrix multiply of the PAT coefficients with the vertices before/after the operation but would save significantly on overhead. Does this sound reasonable? Finally with regard to the 1.5m object target, an old application (that we are replacing) uses a method of culling whereby the smallest 80% of objects are culled from the application as you move around the scene. This significantly reduces render time, but memory overhead is still very high. Ideally I would like to use paging but not sure how this is possible as we need to serialize our custom properties (such as Primitive Type, cylinder radius 1, 2, length etc) with the objects as they are saved. Any help would be greatly appreciated, Thank you, Andrew Thompson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
