Re: [osg-users] Drawing a simple sphere...
Hi,
I recall a post from some days ago, describing problems with the
llvm-gcc compiler and osg on lion. The app hang/crash on a call to cosf.
The solution was to switch to the gcc compiler.
Perhaps the same issue as yours?
cheers,
Stephan
Am 26.08.11 01:07, schrieb Yann Blaudin de Thé:
Hi Ulrich,
It is through my own application. What did you pass as arguments to
cmake? I used :
OSG_WINDOWING_SYSTEM=Coca
CMAKE_ARCHITECTURE='i386;x86_64'
OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX=imageio
CMAKE_BUILD_TYPE=Release
Le 25 août 2011 à 09:50, Ulrich Hertlein a écrit :
Hi Yann,
On 24/08/11 23:17 , Yann Blaudin de Thé wrote:
#include osg/Shape
#include osg/ShapeDrawable
#include osg/Geode
#include osgViewer/Viewer
int main(int argc, char *argv[]) {
osg::Group* root = new osg::Group;
osg::Geode* geode = new osg::Geode();
geode-addDrawable(new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.,0.,0.), 1.)));
root-addChild( geode );
osgViewer::Viewer viewer;
viewer.setSceneData( root );
viewer.realize();
while( !viewer.done() )
viewer.frame();
return 0;
}
No idea - it looks fine and works for me (also on Lion).
Your best bet is probably to run it from gdb and see where it barfs.
When you say loading a .3ds works fine, is that through osgviewer or your
own application?
HTH,
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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] FBX: skinned mesh messed up
Hi Michael, do not apologize for the late answer, as you can see my own reply is quite late too :) Talking about the issue, frankly speaking I cannot answer your questions, the example I sent comes from simplifying some more complex models that were prepared by character animators, maybe merging skeletons into one would work. Cheers. Alessandro PS: good luck with your new job :) On Mon, Aug 15, 2011 at 3:31 PM, Michael Platings mplati...@gmail.com wrote: Hi Alessandro, thanks for the example. osgAnimation only allows one skeleton per RigGeometry, and the FBX importer assumes that no more than one skeleton will be attached to a mesh, hence the messed up results. Can you explain why multiple skeletons are attached? If the importer merged the skeletons into one would that be OK? Apologies for the delayed response btw, I've switched jobs so I don't have much time to spend on this any more but I'll still try to help occasionally. Cheers -Michael On 17 July 2011 11:31, Alessandro Terenzi a.tere...@gmail.com wrote: Hi I finally managed to make a simple model that shows an issue I usually experience with skinned characters, ie the mesh is messed up when imported in OSG. I'm attaching a very simple FBX model: 1 mesh, 2 bones systems and a dummy object used to control one of the bones systems, no animations at all. I created the model in 3dsMax and noticed that the problem appears if there are 2 bones systems (4 bones) attached to the same mesh and one system is also linked to a dummy object (see the example I'm attaching) - if there is just one system (2 bones) and it is linked to a dummy then the problem does not appear. QuickTime displays the mesh correctly while osgviewer does not (OSG v3.0.0 - FBX 2012 and 2011). Please (Michael P. or anyone with expertise in osgAnimation) can you have a look at the model and let me know if I can provide more examples or help to solve the issue? Thanks. Alessandro -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41412#41412 Attachments: http://forum.openscenegraph.org//files/osgviewer_2011_07_17_12_21_22_84_209.png http://forum.openscenegraph.org//files/test_284.zip ___ 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] [osgCompute] Problem about osgCUDA::Geometry
HI Zhen,
In normal OpenGL/OSG usage VBO+EBO's do not take long to create.
Whether osgCuda is the bottleneck or whether it's the crazy number of
primitives you trying to add that might be the problem I can't say. I
havn't used osgCuda myself so can't comment on this specifically.
However, I can say that for best performance with OpenGL applications
it's best to keep the number of separate batches of geometry down.
Which it be possible to cut the number of primitives sets down to 1 by
just using a DrawElementUShort/UInt?
Robert.
On Fri, Aug 26, 2011 at 4:31 AM, Zhen Xu martin31...@gmail.com wrote:
Hi,
I find:
if geom-setUseVertexBufferObjects(true), the process of addPrimitive() is
also very long.
for example:
osg::Geometry* geometry = new osg::Geometry;
geom-setUseVertexBufferObjects(true)
for (unsigned int i=0;i6;i++)
{
geometry-addPrimitiveSet( otherGeometry-getPrimitiveSet(i) );
}
The running time is also more than 10 minutes.
So I quess, osgCuda::Geometry is creating VBO and EBO when many PrimitiveSets
are added into.
I haven't read the source code about VBO and EBO, and I don't know why the
process of creating VBO and EBO is so long if the number of PrimitiveSets is
large.
Thank you!
Cheers,
Zhen
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=42249#42249
___
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] Windows of the viewer freezing when in a separate thread (Boost)
Hi Fred, The osgQtBrowser example has a code path this creates runs a viewer in a background thread, this is done to workaround limitations of threading in Qt. This background thread is an OpenThreads::Thread rather than a boost one, I don't see why using a boost thread would cause a particular problem. Perhaps the issue is a Windows specific problem. Robert. On Fri, Aug 26, 2011 at 3:09 AM, Fred Maulir wallys...@live.com wrote: Hello to All, I recently wanted to use OSG in a separate thread (a thread created with the Boost library) although I encounter a new issue. When I run the viewer in this separate thread the window that is created is completely frozen. The scene is correctly rendered in the window (and the scene is animated also) but the window is frozen meaning that I can't move/reduced/maximize the window. Also I can't anymore use the mouse to navigate in my scene (i have a camera manipulator). Of course I tested everything outside of this thread (in the main thread) and all the bugs disappeared. Can anyone help me about this problem ? I'm sure that I'm not the only one to face this problem but I couldn't find a post related in the forum. Feel free to redirect me to any pre-existing post if you know any. Thanks a lot for any answer. Have a good day. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42247#42247 ___ 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] [osgCompute] Problem about osgCUDA::Geometry
Hi Zhen, hi Robert, You are right Zhen, osgCuda::Geometry always creates vertex buffers br and/or element buffers. CUDA can only handle this kind of OpenGL geometry. br However, osgCuda does not introduce any new operation to the implementation br of osg::Geometry in case you use it in the rendering process only. It maybe synchronizes memory in a cuda operation in case you writebr into a geometry's memory from the CPU (e.g. if you have called map() br with osgCompute::MAP_HOST_TARGET). Otherwise there is no overhead brintroduced by osgCuda. I agree with Robert. Maybe you should check your primitive count. Best regards, Jens -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42255#42255 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Autoshadow aliasing in shadow maps
Hi Justo, Take a look to the Variante Shadow Map algorithmhttp://developer.nvidia.com/node/165 to apply shadow on the scene. Instead of use default OpenGL ShadowMap comparaison technique, this algorithm provide a different way to capture and apply shadow. This technique take more resource but with a better result. HTH David Callu 2011/8/25 Robert Osfield robert.osfi...@gmail.com Hi Justo, Surfaces that are parallel to the light source will be subject to numerical aliasing issues that will mean that either the fragment is inside or outside that shadow map. You can't avoid these aliasing issues completely but if the vertex and fragment shaders are set up correctly then the parallel surfaces should in theory have the same ambient lighting regardless of being in the shadow or not so you shouldn't see the aliasing artifact. I have just developed a new shadow technique that you'll find checked into svn/trunk, look for the ViewDependentShadowMap, use the --vdsm option in osgshadow example. All going well this will replace the collection of other shadow techniques. I would recommend testing against this new technique. Robert. On Thu, Aug 25, 2011 at 7:12 PM, Justo Ureña chil...@hotmail.com wrote: Hi, I´m testing diferent shadows techniques for my scene, and after some adjusts, I got them working fine... Except for very big aliasing that appears in some surfaces that are parallel to the light direction. It happens in all the shadow maps techniques (ShadowMap, StandardShadowMap, LISPSM)... and I´ve tried all the things that I could imagine to get rid of them without success... Please, anyone can help me with that? From my investigation I got that the problem is that the depth map calculated by the shadow camera does not fit exactly with the curved shape in the scene. In the attachment you can see a render of the scene (that only includes the cessna and a vertical directional light that produces the shadow) coloured with the depth map. As you can see, in the laterals of the cessna appear these withe stiches that means that the depth calculated in these texels of the map is infinite, what is obviously wrong. There is any way to avoid this annoying effect? Thank you very much! Cheers, Justo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42241#42241 ___ 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] Android Development Plans
Jorge Izquierdo Ciges wrote: Another issue is missing statistics, probably HUD shader is needed. No shaders - no hud. Hi, I see that the stats HUD does not work in GLES2 and I see this post a few months old. Did anything change in that area since then? If not, I will try to find a fix/workaround and let you know in case I succeed. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42257#42257 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with OSG in Mac OSX 10.7 (lion). Don't show window when load a model.
Hi, Thanks! It solved my problem ... Thank you! Cheers, Josafá -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42258#42258 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows of the viewer freezing when in a separate thread (Boost)
Hey. Thanks Robert for your help. I just figured out what was the problem. In fact I was calling the constructor of the osgViewer in a different thread that the viewer.frame() function. This cause a quite strange issue as the viewer correctly render the scene but does not response to any manipulator. I guess this is due to the fact that the windows handlers are linked to the creation thread and not the execution thread. Thanks any way for your help. Have a great day. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42259#42259 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawing a simple sphere...
Hi Yann, On 26/08/11 1:07 , Yann Blaudin de Thé wrote: Hi Ulrich, It is through my own application. What did you pass as arguments to cmake? I used : OSG_WINDOWING_SYSTEM=Coca CMAKE_ARCHITECTURE='i386;x86_64' OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX=imageio CMAKE_BUILD_TYPE=Release Good point, I was actually using a CMakeCache from SnowLeopard and it's settings were the same except: SDK=10.6, CMAKE_ARCHITECTURES=x86_64 (no i386) Currently my Lion build fails in DarwinUtils.mm /Users/uli/Projects/osg/OpenSceneGraph/src/osgViewer/DarwinUtils.mm: In member function 'virtual void osgDarwin::DarwinWindowingSystemInterface::getScreenSettings(const osg::GraphicsContext::ScreenIdentifier, osg::GraphicsContext::ScreenSettings)': /Users/uli/Projects/osg/OpenSceneGraph/src/osgViewer/DarwinUtils.mm:316: error: 'CGDisplayBitsPerPixel' was not declared in this scope :-( Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I made the libRocket GUI library usable with OSG
On Fri, 2011-08-26 at 06:38 +0200, Martin Scheffler wrote: Hi all, On a long train ride yesterday I had the chance to work on my osg implementation of a libRocket interface. You can download the code from the attachment. libRocket is a nice little GUI library that seems to be well thought through and cleanly coded. There is an html-like format for writing GUIs. I have not yet fully explored the library, but now that I can use it in OSG I surely will. What it can do at this point: * Create fullscreen GUIs * Create in-scene GUIs * Mouse and keyboard events are transformed to GUI coordinates and forwarded to libRocket system That's all, and I think that is all that is needed. I don't think I will wrap any other libRocket functionality as it is all accessible. The included example shows two GUIs. One is full screen, the other is in-scene and can be rotated with the default osgViewer mouse manipulator. If anyone is interested in this I can put it on source control somewhere. Please give me feedback on what is missing or what can be improved! Having made osgWidget all those years ago it really makes me sad when I see stuff like this, but the bottom line is osgWidget simply isn't good enough. I've wanted to, for a long, long, time, go back and make it better. :) HOWEVER, having said that, this is actually a great little library. Not bad at all, the design seems very solid! I think if you figure out the issues with cleaning up, it could become quite popular in the OSG community. BTW: I can't actually get it to compile yet (though I can run the Rocket examples just fine); CMake won't find/define LIBROCKET_* variables... Cheers, Martin [/img] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42250#42250 ___ 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] I made the libRocket GUI library usable with OSG
Hi Martin, This sounds very interesting! I've always wanted to be able to create interfaces for my application using HTML/CSS. I'm definitely going to have a look at this. Thanks, Farshid On Thu, Aug 25, 2011 at 9:38 PM, Martin Scheffler osgfo...@tevs.eu wrote: Hi all, On a long train ride yesterday I had the chance to work on my osg implementation of a libRocket interface. You can download the code from the attachment. libRocket is a nice little GUI library that seems to be well thought through and cleanly coded. There is an html-like format for writing GUIs. I have not yet fully explored the library, but now that I can use it in OSG I surely will. What it can do at this point: * Create fullscreen GUIs * Create in-scene GUIs * Mouse and keyboard events are transformed to GUI coordinates and forwarded to libRocket system That's all, and I think that is all that is needed. I don't think I will wrap any other libRocket functionality as it is all accessible. The included example shows two GUIs. One is full screen, the other is in-scene and can be rotated with the default osgViewer mouse manipulator. If anyone is interested in this I can put it on source control somewhere. Please give me feedback on what is missing or what can be improved! Cheers, Martin [/img] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42250#42250 ___ 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] Wiki pollution
Jorge Izquierdo Ciges wrote: I don't know how if the wiki is down. 2011/8/25 Chris 'Xenon' Hanson () Spammers seem to have found the wiki: http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/GiftBaskets (http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/GiftBaskets) http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/X-RayRecycling (http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/X-RayRecycling) -- Chris 'Xenon' Hanson, omo sanza lettere. http://www.alphapixel.com/ (http://www.alphapixel.com/) Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) -- Post generated by Mail2Forum must have sliped it in just before and/or might be the reasion its down! Spammers, Grumble Grumble! I hate Spammers, Grumble Grumble! D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42263#42263 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android Development Plans
There's no upgrade to that. I usually get the statistics from the functions and get the values by myself withouth the auto stats screen. I don't know if it's possible to show them in pc withouth fixed pipeline if you can then it shoul be just a matter of fixing the automated shaders by adding a default precission mode. OSG makes that shaders GLSL compilant BUT Gles 2.0 states that they ALSO need a precission value thus not exactly conformant to GLSL. 2011/8/26 Luca Vezzadini luca.vezzad...@gmail.com Jorge Izquierdo Ciges wrote: Another issue is missing statistics, probably HUD shader is needed. No shaders - no hud. Hi, I see that the stats HUD does not work in GLES2 and I see this post a few months old. Did anything change in that area since then? If not, I will try to find a fix/workaround and let you know in case I succeed. Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42257#42257 ___ 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] Drawing a simple sphere...
On 26/08/11 16:39 , Ulrich Hertlein wrote: Currently my Lion build fails in DarwinUtils.mm /Users/uli/Projects/osg/OpenSceneGraph/src/osgViewer/DarwinUtils.mm: In member function 'virtual void osgDarwin::DarwinWindowingSystemInterface::getScreenSettings(const osg::GraphicsContext::ScreenIdentifier, osg::GraphicsContext::ScreenSettings)': /Users/uli/Projects/osg/OpenSceneGraph/src/osgViewer/DarwinUtils.mm:316: error: 'CGDisplayBitsPerPixel' was not declared in this scope Okay, I've found a work-around for the deprecated CGDisplayBitsPerPixel in Lion SDK 10.7, cleaning that up now. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.8.3 3.0.1 view dependent shadowclippingplane
Hi All, I have checked in a couple of bug fixes to the new ViewDependentShadowMap technique so please update to latest svn/trunk and then test it out. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Autoshadow aliasing in shadow maps
Hi, thank you Robert and David for your answers, I really appreciate them. I have just developed a new shadow technique that you'll find checked into svn/trunk, look for the ViewDependentShadowMap, use the --vdsm option in osgshadow example. All going well this will replace the collection of other shadow techniques. I would recommend testing against this new technique. I´ve tried the ViewDependentShadowMap and although it works great, I still have the same problem with the stiching due to the missing tessels... Robert, you´re right about that in a normal illumination, these surfaces should be set to the ambient colour, cause their normals are pendicular with the light direction. But as my scene is an outside static scene, and I don´t want to illuminate a big portion of the scene with the ambient light because it looks flat, I´m trying to implement some kind of hemispheric lighting (from the glsl orange book), but without renouncing to the shadow effect. So, I need this perpendicular surfaces to be lit, and to show the shadows... Take a look to the Variante Shadow Map algorithm to apply shadow on the scene. Instead of use default OpenGL ShadowMap comparaison technique, this algorithm provide a different way to capture and apply shadow. This technique take more resource but with a better result. I´ve already tested another filters as PCF, but the results weren´t so good and it consumed a lot of resources. I´ve read about the VSM algorithm, and I was doubting about implementing it. I think that I´m gonna try it, and I´ll let you know the results. Hopefully it will get rid of the problem. Hopefully! Thank you very much guys! PS: Anyway, I´m still curious with the missing texels problem. I´ve been investigating about it and I couldn´t get anything... Isn´t there any way to make the RTT camera to set the depth of this texel to the fragments one? Do you have any hint about it? Thanks again. Cheers, Justo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42268#42268 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Autoshadow aliasing in shadow maps
Hi Justo, PS: Anyway, I´m still curious with the missing texels problem. I´ve been investigating about it and I couldn´t get anything... Isn´t there any way to make the RTT camera to set the depth of this texel to the fragments one? Do you have any hint about it? There aren't any missing texels as you seem to think. In shadow map space, that area simply maps nowhere (it falls between 2 texels). You have 2 options: higher shadow map resolution so that the area where this happens is smaller, or do some filtering to hide the effect. We had a similar effect where we would get a kind of moiré pattern over surfaces. It was most visible on very white surfaces and when the shadow map was stretched over a large area. Zoomed up close, the appearance was identical to what you have. In our case simple PCF filtering worked for us, but you say you've tried it and rejected it. You could try some other type of filtering, or increase your shadow map resolution, though I doubt you'll get to a point where the artifact is not visible while keeping a reasonable resolution... For us it was still visible at 4096^2 resolution, so filtering was the best we could do. Unfortunately this is the kind of thing (like z-buffer precision leading to z-fighting) where you just have to know what the artifacts could be, and manage all your options so you minimize the appearance of the artifacts. There is no perfect solution. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] Problem about osgCUDA::Geometry
Hi Jens，Hi Robert， I have read the source code of osgCompute and I find my problem is caused by the large number of PrimitiveSet, not a bottleneck of osgCuda::Geometry. osgCuda is very good and I will do some research about FEM with osgCuda . In next step, I will reduce the number of Primitive in my model. Thank you! Cheers, Zhen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42269#42269 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgCompute] Question about map() of index buffer
Hi, From web of osgCompute, I find a geometrie's index buffer can be mapped, as follows: osg::ref_ptrosgCompute::Memory memory = memoryAdapter-getMemory(); void* devInd = memory-map( osgCompute::MAP_DEVICE_INDICES ); When I read the source code of osgCuda::Geometry, I found some problem as follows: 1. MAP_DEVICE_INDICES is defined in namespace osgCuda, rather than osgCompute. 2. Map of index buffer is implemented in Class IndexedGeometryMemory, but the class member _memory is initialized as Class GeometryMemory in the constructor of osgCuda::Geometry. In this way, the function map() is not related with index buffer. So I think the codes above can't realize map() of index buffer. In fact, My geometry utilizs many DrawElementsUInt, but the return value of map( osgCuda::MAP_DEVICE_INDICES ) is NULL. I have revised the source code of osgCompute, but it still doesn't work. So I want to know the reason of the failure about map of index buffer. Thank you! Cheers, Zhen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42271#42271 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I made the libRocket GUI library usable with OSG
Hi Jeremy, I hope I haven't discouraged you from continuing development on osgWidget! A native osg gui would have a lot of advantages over an external library. The main reason I did not consider osg widget was the lack of documentation, so maybe you can invest some time in that... About the missing CMake variables: Are you using the advanced mode in cmake-gui? The libRocket variables are marked as advanced, I have not yet hd time to find out how to mark them as non-advanced. Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42272#42272 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
