Re: [osg-users] Render To Texture with osgFX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Look into osgHud and osgShadow for examples of RTT. You don't need osgFX, only a Camera and an FBO to set as the appropriate buffer, color or depth. You might want to use osgFX if multitexturing is involved when using the textures you generated. Mihai Benoit bossavit wrote: Hi, How can I do a multi-pass rendering using Render To Texture with osgFX? Where can I add my Camera and attach it a texture? There is some examples? thanks, bnua ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRpvaN1rOOUK3PONYAQK3BQf/Y0Rn+DxfGClOmQcJFJAmr8hiMr9mbm6q 2PmhhmsjJ6I053EbXGtP9GTZ+zDMS05RY/AZw3Becd6imiMxXO8Eo/ApVupiJa7Q pfrjtpvrDvo1dzRMHFKT8HJi2X6bJZ9k+AnQ0CocterKdhpHB5RxXJ9XAL745cBR 72AsOfH8WMTDKAVWHztLf7mqlDh6gCSL8fBG7i4wYKvk6yPc8I4AFRKmOv6PnqXo CKO7TS8BIOHq9AvUw3MQL4a7s0ycCQ92M8LM0H6P25rXxIozGnSQrx/vNuBDkXWN 8hGI6Zb4go6uVjjZWafWn2BVQCpUthjyBcIlqrglFeCjMb1qgJ8rpQ== =awPE -END PGP SIGNATURE- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OsgShadow shadow volume strange bug
Hi Alexandre, I've been working with shadowMap for the last couple of months, on a modified osg 1.2, but the code is almost identical. What errors are you seeing with that one ? Cheers Mihai amalric alexandre wrote: Hi Robert, Ok thank you, I see that osgShadow is a complicated work, shadowMap technique is also displaying something strange. I'm sure that osg community will find how to improve shadows ;-) 2007/7/11, Robert Osfield [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi, This is a know bug. ShadowVolume code isn't yet tracking matrix updates. Robert. On 7/11/07, amalric alexandre [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi osg-users, I've noticed a strange behavior on Example osgshadow with command --sv (to have shadow volume). When shadow overlap each other they cancel them, if I'm not very clear see the sceen capture attached. Is it a known bug ?? I use OSG 2.1 on a geforce 7900GS. ___ osg-users mailing list osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Build a new machine, comments?
Robert Osfield wrote: Hi Leif, On 7/13/07, Leif Delgass [EMAIL PROTECTED] wrote: A word of warning: you might consider looking at a roomier case or at least check the dimensions carefully. The new GeForce cards (even the GTS) are quite long and you may be in danger of bumping up against the drive cage with that case. I have a Tsunami case as well, and although I haven't tried the GeForce 8 cards yet, I am considering a larger case to accomodate the newer boards, since the 7900GTs I have are already a tight fit. I have Thermaltake Tsunami already at it comfortably house my twin 7800GT's so made the assumption that it'd work fine for 8800GTS... thank for the heads up. Now need to find out how big the 8800GTS is... It's just as long as a 7800GTS and 7900 GTS also, from what I remember. A dual-slot card, for the cooling, so the width would be more of an issue than the length. 8800 GTS 640Mb it's the card I got for my new machine, it works very nicely and fits just fine in a mini-tower case, SilverStone TJ04. Ceers Mihai ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] fixing back-projection texturing with fixed functionality
Hello, I've been trying to solve the back-projection issue when doing projective texturing, with the goal of having it work with shadow maps. I know the simplest thing is to use a shader, and that part is already working, it's the 'support older hardware' requirement that's biting me. I modified the 'osgshadowtexure' example by adding a 1D texture that maps to the r coordinate used by the projective TexGen and trying to use this to control the application of the shadow texture. The idea is to give the projected texture an alpha of 0 (invisible) when it has negative r coordinate, using TexEnvCombine. I almost got the result I was looking for, but it not only wipes out the shadow texture, but the base texture as well. The frustrating thing is that it seems that 'setCombine_Alpha' is being ignored, and I can't see an RGB operation that will give the proper result. The example is meant to be dropped into the examples dir in the sources, then added to the CMakeLists.txt file. There was another thread dealing with a similar issue 'TexGenNode TexEnvCombine' but while David mentioned using a masking texture, there were no details. Cheers Mihai Radu osgshadow-backproj.7z Description: Binary data ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] GLSL changes from OSG 1.0 to 1.2?
I have also ran into this kind of problem moving from 1.0 to 1.2 (osgProducer). The set-up is similar, a uniform with default value at the root group: root-getOrSetStateSet()- addUniform(new Uniform(uTextured,true)) then nodes can have this overridden: node-getOrSetStateSet()- addUniform(new Uniform(uTextured,false)) The problem is that in some cases the node will not use the custom value of the uniform when it's being drawn. The frustrating part is that this appears sometimes based on the viewing direction of the camera in the scene (when using a bunch of nodes with the custom Uniform added to them). I am also getting some strange behavior when updating values for Uniform(s), sometimes the new value is not used right away, there is a delay till some other scene property is modified; in this particular case it's a bool Uniform that flags if fog is being used, the new value is ignored until the fog density is updated ( this is the regular GL property). This makes me think that there should be some kind of 'dirty' that is not being applied/called when updating/adding an uniform. I realize the standard answer is to move to the new viewer code, but that is not an option for some of our projects since they are close to delivery and we can't use an unstable code-base for that. Maybe there is some fix that has been applied to the svn version that can be back-ported to 1.2. As far as providing some code for illustration, I couldn't reproduce it with a simple example, and the application is too tightly integrated with the physics engine to provide some code samples that make sense. I hope we'll get to figure this one out soon Mihai Mike Weiblen wrote: Hi, um ok, so can anyone give me a concise repro to diagnose? I'm willing to help, but only have a vague description along the lines of things seem to work fine except for the shader-related Uniforms. I've used hierarchies of uniforms and it has worked for me; perhaps you've found a corner case? Cheers -- mew ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] How to preload and precompile shader.
Hi Ivan,
Try this before the code creating the program:
osg::setNotifyLevel(osg::INFO);
Then watch the spew on the console to get some idea of supported
extensions, errors etc ...
Mihai
Ivan Bolina wrote:
Nvidia 6600 GT, driver is 9.1.3.1
Thanks and bye,
ivan
2007/3/28, Mike Weiblen [EMAIL PROTECTED]
:
What
GPU and driver?
-- mew
-Original Message-
From: [EMAIL PROTECTED]
[mailto:osg-users-
[EMAIL PROTECTED]
] On Behalf Of Ivan Bolcina
Sent: Wednesday, March 28, 2007 2:21 PM
To: osg users
Subject: Re: [osg-users] How to preload and precompile shader.
It is GLSL.
It is not first frame problem.
I dont know what you mean my displaylists?
That is shader init.
mProg = new osg::Program;
RefPtrosg::Shader fragmentShader = new osg::Shader(
osg::Shader::FRAGMENT );
mProg-addShader( fragmentShader.get() );
fragmentShader-loadShaderSourceFromFile(
"data/blackify.frag");
This is my shader.
uniform float strength;
void main(void)
{
gl_FragColor = vec4(1.0,1.0,1.0,strength);
}
2007/3/28, Mike Weiblen [EMAIL PROTECTED]
:
Hi,
What's your GPU/driver?Is your shader GLSL or ARB FP?
0.5 second build times are way over anything I've seen.I've
run
apps
that rebuild the shaders every frame (not a good idea, but
not
painful
either).Why do you think it's the shader; could it be some
other
1st-frame setup (eg displaylists) going on?
Cheers
-- mew
-Original Message-
From: [EMAIL PROTECTED]
mailto:osg-users-
[EMAIL PROTECTED][mailto:osg-users-
[EMAIL PROTECTED]
] On Behalf Of Ivan Bolcina
Sent: Wednesday, March 28, 2007 8:43 AM
To: osg users
Subject: [osg-users] How to preload and precompile
shader.
Hi.
I am using very simple fragment shader and it works
great. But
there
is a
problem, when I first use ti on scene, it takes about
half a
sec
to
initialize, so my whole app freezes for half a second.
I would like to preload fragment shader and precompile
it. Any
ideas?
Bye, ivan
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] fisheye or wide-angle example code?
Hi Lucas, The basic idea is to have a wide FOV (field-of-view). The implementations are quite different right now, with osg 1.2 using osgProducer ( where you will have to refer to Producer::Camera functions, the ultimate arbiter underneath it all is Producer::Camera::Lens ); in the SVN path osgViewer is the place to look. Of note is that Producer::Camera has a default mode to auto-compute FOV, this can sometimes bite; I don't know if on the osgViwer side there is something similar to handle. I hope this helps Mihai wsacul wrote: Does anyone have any 1.2 compatible code that will do a fisheye or wide angle lense effect? I'm playing around with osgdistortion right now but I'm not able to get it to do what I want. Thanks, Lucas ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] moving to VS8
Hi Mike, I have been usign vc8 osg for some time now, and I do have an updated set for 3rdParty, since we checked the libs needed to our CVS, on hand I have a set without sources that can be used to build osg. I put a 7zip archive here: http://tiganu.googlepages.com/home Let me know if it works for you. Mihai Mike Weiblen wrote: Hi Paul, Ok, no prob. (folks _are_ using VS8, right? What are yall using for 3rd party libs??) Old versions of my installers are still available; if not on the OSG site, then at http://mew.cx/attic/ Cheers -- mew osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Texture repeat
Here's how I scale down a texture, in my case it gets applied to a height-field: float scale = 0.1; osg::TexMat* texmat = new osg::TexMat; osg::StateSet* set = meshGeom-getOrCreateStateSet(); set-setTextureAttributeAndModes(0, texmat, osg::StateAttribute::ON); Cheers Mihai Christian Verbeek wrote: Hi Ulrich, Please give me a hint (a line of code) how to set the texture matrix. As I am new to osg, I would appreciate this a lot. Regards Christian Ulrich Hertlein schrieb: Robert Osfield wrote: On 3/21/07, Christian Verbeek [EMAIL PROTECTED] wrote: Dear osg-users, I want to create a floor textured with a small image being repeated. Thats what I am doing, but the texture is stretched (i.e shown only once). What is wrong? I am using the latest OSG version from SVN. ShapeDrawable doesn't support repeating of texture coordinates. The closest you could get is to use osg::TexMat, but in the end I think it'd be easier just to create the geometry yourslef as you need it. To elaborate on that a bit, ShapeDrawable creates texture coordinates only in the range of 0.0 to 1.0 i.e. the lower-left of the texture in one corner (of your cube) and the upper-right of the texture in the opposite corner. If you place a texture matrix using scale 1000,1000,1 it should look as you expect. Cheers, /ulrich ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: CompositeViewer and computeIntersections
Hi Calin, If you look closely, only that View has a PickHandler added to it. So you use that as a basis for your experiments, once it's behaving how you want it, you can apply other instances of the calss to the various Views. Salut Mihai Calin Negru wrote: I've played a bit with the example. I managed to select the object but I can do it only if the camera is really close to the object and only in the lower-right view. http://calinnegru.googlepages.com/MultipleCamerasSelect.jpg On 3/13/07, Calin Negru [EMAIL PROTECTED] wrote: I've just noticed the SVN version of osgmultiplecameras example is changed. That's pretty close to what I'm looking the only problem with the example is that it doesn't do picking inside windows i.e you can rotate the model in the window even when the cursor is not on top of the object. I'm still studying the code. On 3/13/07, Calin Negru [EMAIL PROTECTED] wrote: Do I use viewer-computeIntersections as usually when the viewer is composite (available in SVN)? How does it know in which of the two cameras I'm doing picking? -- Calin Negru -- Calin Negru -- Calin Negru ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] SVN : this morning
Hi Adrian, >From a quick parsing of the output you gave, I think the problem is that Xcode is trying to build both i386 and ppc (for a Universal target), but it's failing in linking with ppc libraries. Try to set the architecture to only i386 in the project info (Option + i for OpenSceneGraph in the project window) [I'm doing this w/o my mac, so I might give wonky window names :] To use cmake on Osx : 1. download install Osx version 2. open-up Terminal 3. cd to the parent of OpenSceneGraph svn check-out 4. mkdir build-osg cd build-osg 5. cmake -G Xcode ..\OpenSceneGraph\ [make sure -G is the generator switch, cmake --help ] 6. ls -l [ there should have been generated OpenSceneGraph.xcode directory ] 7. open OpenSceneGraph.xcode You will have to do this first with OpenThreads, it's exactly the same if you flip the names. I hope this will helps you. Cheers Mihai Adrian Egli wrote: hi robert sorry about my short email. i had two problems with the latest SVN version: first is the build with Xcode under Mac OS/X tiger. i get the long link error. i tried to link with a /System/Library/Frameworks/AGL.framework. but it doesn't help i still get these link errors. I have to say that i am a really new on OS/X. I had some chf left, and i buied a MAC BOOK PRO dual intel. second problem is, that i never used cmake. i tried to build with cmake . but i doesn't work. how should i try to build it with cmake. thanks a have nice weekend, i go for snowboarding so i will be back monday /adegli 2007/3/10, Robert Osfield [EMAIL PROTECTED]: Hi Adrian, I could parse your email easily, so am a bit losts to what platform and build environment your are using. Are you using cmake?How did you run it?What hardware are you working on? Robert. On 3/9/07, Adrian Egli [EMAIL PROTECTED] wrote: hi i working on testing under osx. the SVN version under windows VS 2003 works without any problems. but now under osX i cant compile it. nor with Xcode nor with cmake. Xcode : can find (OpenThreads and Xcode ok) cd /Users/PWD/dev/OPENSCENEGRAPH_CVS/OpenSceneGraph/Xcode/OpenSceneGraph /usr/bin/g++-4.0 -o /Users/PWD/dev/OPENSCENEGRAPH_CVS/OpenSceneGraph/Xcode/OpenSceneGraph/build/OpenSceneGraph.build/Default/osgViewer.build/Objects-normal/ppc/osgViewer -L/Users/PWD/dev/OPENSCENEGRAPH_CVS/OpenSceneGraph/Xcode/OpenSceneGraph/build/Default -F/Users/PWD/dev/OPENSCENEGRAPH_CVS/OpenSceneGraph/Xcode/OpenSceneGraph/build/Default -F../../../OpenThreads/Xcode/OpenThreads/build/Default -F/Users/PWD/Library/Frameworks -F/Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks -filelist /Users/PWD/dev/OPENSCENEGRAPH_CVS/OpenSceneGraph/Xcode/OpenSceneGraph/build/OpenSceneGraph.build/Default/osgViewer.build/Objects-normal/ppc/osgViewer.LinkFileList -framework osgText -framework OpenGL -framework osg -framework osgUtil /Users/PWD/dev/OPENSCENEGRAPH_CVS/OpenThreads/Xcode/OpenThreads/build/Default/OpenThreads.framework/OpenThreads -framework osgDB -framework osgGA -arch ppc -Wl,-single_module cmake: what should i know, and how can i compile it. first time i have to use cmake ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osg: code for a simple light required
I noticed you never apply the stateset referring to the light to any node. Here's a suggestion: after creating the light node group-addChild(lightSource); // grab a pointer to the group's stateset osg::StateSet* statelightON_OVRD = group-getOrCreateStateSet(); statelightON_OVRD-setAttribute(light, osg::StateAttribute::ON); This way the light is enabled for the group. Mihai ps. also noticed you set the scene data to only the loaded model: viewer.setSceneData (loadedModel.get()); instead: viewer.setSceneData (group.get()); [EMAIL PROTECTED] wrote: Hello!! Its my first email to the community! I have been to the website and I foudn the codes examples. I am trying to adda simple light or spot light to my scene graf!! However I am not very skilled in coding, and I have an unclean code... I dont know where its my mistake or how to adapt the lamp to my code! Basically I copied: I attached my code in join file so you can have a look if required!/ I believe the problem is there: // create the light osg::StateSet* statelightON_OVRD = new osg::StateSet(); osg::LightSource* lightSource = new osg::LightSource; osg::Light* light = lightSource-getLight(); light-setLightNum(0); light-setPosition(osg::Vec4(0.0f,0.0f,0.0f,1.0f)); // directional light from above light-setAmbient(osg::Vec4(0.8f,0.8f,0.8f,1.0f)); light-setDiffuse(osg::Vec4(0.2f,0.2f,0.2f,1.0f)); light-setSpecular(osg::Vec4(0.2f,0.2f,0.2f,1.0f)); light-setSpotExponent(50.0); light-setDirection(osg::Vec3(1,1,-1)); statelightON_OVRD-setAttribute(light, osg::StateAttribute::ON); group-addChild(lightSource); // mtTwo-addChild(loadedModel); mtTwo-setStateSet(stateTwoFogON_OVRD); loadedModel-setStateSet(stateTwoFogON_OVRD); // mtTwo-setStateSet(statelightON_OVRD); but Maybve its somewhere else!!! Cheers! Jean ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Moving 2D graphics on the HUD
If you want to just move the position of a texture on a fixed geometry, an alternative is to use a TexMat node (texture matrix) that will be multiplied with the texture coordinates. Updating is done just as Thibault suggested, with a callback. To see it in action check osgtexturerectangle example. Mihai Calin Negru wrote: Thanks! On 3/6/07, Thibault Genessay [EMAIL PROTECTED] wrote: Hi Calin On 3/7/07, Calin Negru [EMAIL PROTECTED] wrote: How can I get 2D images moving on the screen? I managed to display a static HUD however I can't figure out how to get the cursor graphics moving on screen. I took glance at osgcatch but the code is too complicated (and I'm looking for a quick fix ). To set the HUD position on the screen I feed a osg::geometry object with a coordinates array. Is there a way to move the geometry position at runtime? You can just add your geode - the one that contains your geometry - as a child of a MatrixTransform or PositionAttitudeTransform. Then moving your HUD around only takes a change in the Matrix/Vec3-Quat of the transform node. You have to do this change during the update() phase of the main loop; using an update callback is probably the best way. Have a look at the osggeometry example: it has a moving background that uses this technique. -- Thibault -- Calin Negru ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] SLI
Hi Robert, I do agree with you that the current state of SLI is geared towards gamers that want to post their out-of-this world FPS scores ... ignoring anything else. Thinking about it, I think a nice direction would be to use a system like CUDA to do a computation pass on one card, not sure what will benefit the most, what comes to mind would be particle systems, occluder geometries shadow volume extrusion etc ... , that way one card will prepare vertex data for the second one that does the rendering. At least the card companies seem to go towards opening up these extensions. Mihai Robert Osfield wrote: Hi Mathieu, I haven't tried SLI yet, but I have read some docs from NVidia about getting best performance from SLI and it looks like they don't want to app to do things like using glViewport which the OSG does, there are a few other odd cavates. I suspect NVidia and ATI have various driver detection hacks to tweak things for games to twist things to their own rules. SLI is basically a hack to make single threaded, single graphics context applications work on two graphics cards. It's shoddy way to do things that only can help in fill limited apps. Its much better to do this type of management at the scene graph level, something that the OSG is capable of, and particularily well suited for taking advantage of multi-core CPU and dual GPU machines. The only stumbling block is that the compositing that SLI does is not something that has extension to support yet, and this I find *very* frustrating. Personally I'm pretty appalled by the literature that NVidia has pushed out about SLI, they recommend things like disabling Vsync to prevent the latency of AFR(alternative frame rendering) from killing response times, yet never mention about the bad effects it has on visual quality. What is the point of being able to double anti-aliasing for better visual quality if you visual quality is destroyed by tearing? Its totally taking the piss, a clear indication that marketing driods have won the battle. Its so sad that such great hardware gets sucked off with nonsense like this, rather than messing around with hacky drivers to get slightly better frame rates with vsync off they should spend their time on exposing extensions to help us graphics professional make use the best use of their hardware. Robert. On 3/5/07, Mathieu MARACHE [EMAIL PROTECTED] wrote: Hi all, I've looked throughout the mail archive for a explicit use of SLI (2 cards for one output) and didn't find any, the only use found is 2 cards 2 outputs. I did some testing under Windows and Linux and neither tests did have any noticeable acceleration using any of the SLI modes (AFR or SFR) Did anybody tried to use OSG in SLI mode and thus was able to have noticeable acceleration or is this a 'feature' and OSG can't by design use SLI configurations ? -- Mathieu ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Shadows and depth component.
Hi Kenneth, I was curious about this question too, and I did a bit of digging, the results: the following code does the same thing as just creating the texture, so you can see it's a float format osg::Image* image = new osg::Image; image-allocateImage(tex_width,tex_height,1,GL_DEPTH_COMPONENT, GL_FLOAT); osg::Texture2D* texture = new osg::Texture2D; texture-setInternalFormatMode(osg::Texture::USE_IMAGE_DATA_FORMAT); //texture-setTextureSize(tex_width, tex_height); //texture-setInternalFormat(GL_DEPTH_COMPONENT); texture-setImage(image); texture-setShadowComparison(true); texture-setShadowTextureMode(Texture::LUMINANCE); texture-setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR); texture-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR); The hex number for the format is 0x1902, after a bit of digging found it defined in gl.has #define GL_DEPTH_COMPONENT0x1902 So the short story is that yes, it is a float 32-bit pixel format. And it's not quite a newbie question :) BTW. in the svn version, use the osgShadow nodekit, it gives you the same features with ShadowMap as the osgshadow example, and it also has ShadowVolume implementation ( more importantly is in active development, so it will get better ). For large-scene shadow mapping, optimizations need to go beyond larger maps, here's a small list of the top of my head : 1. use the main camera frustum to clip the scene for the shadow pass ( will clip a lot of the terrain some cases, in others it's less efficient) 2. Skew the shadow pass projection to give more importance to texels mapped close to the main camera position ( ref. Light-Space Perspective Shadow Map [Wimmer05] in Shader X4) 3. Use multiple shadow maps, arranged by partitioning the main camera frustum along z-axis (ref. PSSM in the list) I hope this helped a bit Mihai Sewell, Kenneth R CTR USAF AFRL/SNZW wrote: I used osgdepthshadow as a guide for implementing shadows in my own program. I got the shadows working but I have a question about the shadow map. By default what depth is the shadow map?(8-bit, 16-bit, ...) I'm casting my shadow over a large area and I'm seeing some banding and other artifacts. I looked through the OSG code and noticed GL_DEPTH_COMPONENT16, GL_DEPTH_COMPONENT24 and GL_DEPTH_COMPONENT32. I did not see any usage of them in the examples though, are they used in the texture's setInternalFormat() call? OpenGL gives me an 'invalid operation' error when I tried them. Am I on the right track? Is there more to it? I've never tried shadows in OSG (or OpenGL) before so I apologize for the newbie question. Ken. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Windows Vista
Hi, I had problems with Vistan on a MacBook pro, svn compiled fine with VS2005(sp1 + patch), but when the viewer was realized, all I got was a black screen, and the machine froze (looks like the graphics froze). I blame ATI and their drivers (using the latest mobility drivers from the ati site) hardware: Intel Core Duo ati X1600 mobile 128mb 1.5 Gb ram Anybody has any experience with vista ati ? Cheers Mihai Adrian Egli wrote: Hi, (1) Windows Vista and OSG works, after we installed the latest graphic driver, everything works like on an other windows (xp) machine. (2) everybody in my country talk about the engery troubles and clime change we will go in in the next few years. why should the world go using vista? i don't know, or is the microsoft company powered by the engery like 2u bush. :-) Anders do you have some benchmark showing exactly the issue 20% more energy conumption using vista compared to xp. so may we can write some nice things, i guess there will be some politics being interested in such a idee, in switzerland the will add some extra tax / penalties for huge energy consumption cars, machnines and so on. 2007/2/21, Anders Backman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Well, if 20% of all windowsXP users switch to vista today, the CPU energy consumption (even on idle) will go up quite a lot (my laptop is averaging on 20% doing nothing), the fan is running constantly, its always warm. So I would say it consumes about twice as much energy... This would also make the energyconsumption go up quite a bit. Not what you would like to see for the world, right? People will by newer faster machine to cope with VISTA, which will make the energy consumption go up even higher. Didn't Bill look at An Inconvenient Truth? Funny article regarding updating to Vista: http://www.theregister.co.uk/2007/02/14/pricey_beta_bugger/ http://www.theregister.co.uk/2007/02/14/pricey_beta_bugger/ /Anders On 2/21/07, *Gerrick Bivins* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Our app (VE-Suite) has been running on Vista as usual. We've installed it on various configs such as a laptop with a 6800 Go card and even a lowly p4 with fx 5200. No problems. The 5200 is using driver 97.46 (which is the only one that supports the 5200) and the lappy is using the latest and greatest. biv On 2/21/07, *Gordon Tomlinson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: OpenGL Sucks on Vista right now and direct X is not much better Thats what we have found any way, Nvidia is hurting on Vista at this time. As a company we do see Vista a a platform right now, our customer base wont touch it for at least 2 years __ / Gordon Tomlinson // Email /: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]/ YIM/AIM/: Gordon3dBrit /MSN IM /: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]/ Website/ : www. 3dscenegraph.com http://3dscenegraph.com/ __ Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - */Master Tambo Tetsura/* *From:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] *On Behalf Of *Adrian Egli *Sent:* Wednesday, February 21, 2007 6:29 AM *To:* osg users *Subject:* [osg-users] Windows Vista hi i have a windows vista since yesterday, i will test osg on it as soon as possible, what are others expirience ? /Adegli ___ osg-users mailing list osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Anders Backman Email: [EMAIL PROTECTED]
Re: [osg-users] osgShadow::ShadowMap implementation
On Mon, 2007-02-19 at 14:35 +, Robert Osfield wrote: Hi Radu, On 2/19/07, Radu Mihai [EMAIL PROTECTED] wrote: I just saw ShadowTexture implementation from svn, I'll look over it and maybe get the ShadowMap done following it as a template (looks like the place I was got stuck was using different traversal masks for the cull+draw traversal). I've done a basic port of osgdepthshadow to ShadowMap now too, so svn update :-) Saw it :) Had to wait for a couple of fixes while I was building, but now [ rev. 6238 ] it works very nicely. There is still a lot one could do to improve both ShadowTexture and ShadowMap, in few key areas: - ability to handle wide range of model types - such as some objects with textures, some without I have done this before, by using a bool Uniform to control the texturing. On the first implementation, I had a flag when adding to the scenegraph. As an improvement, I was thinking of testing the models for texturing ( at addition or update ) , I'm not sure if the steps below are sufficient : Visit the model, test each Drawable for StateSet-textureAttribute and set the Uniform accordingly Any suggestions for some code that does something similar wold be very welcome. - what happens when multiple lights are used This should be interesting, and very close to PSSM for 1 light. - make the same area view dependent so that as you move around a large scene the part of the scene that the texture covers moves. When using spotlights this is much easier, as the spot's parameters can be used. - use of texture projection that creates a trapezoidal mapping rather than a rectangular one, I forgot the official name of the technique... the idea is create a better balance of texels for objects near the eye vs at the far plane. I think there are a couple of names for different implementations of this [ from GpuGems 1 ShaderX4 ]: Perspective Shadow Maps [Stamminger02] Light Space Perspective Shadow Maps [Wimmer04] There are also technique specific parameters that one could tweak. Bias for the PolygonOffset and bias for SM look-up come to mind. ShadowTechnique is never going to be that powerful, ShadowMap will be better, but I expect ShadowVolume and ParallelSplitShadowMap to be the real high quality solutions. Each of these different techniques will have their own strong points/weaknesses. Since we now have two image based ShadowTechniques checked in I'm hoping that it won't take much more to add support for ParallelSplitShadowMap. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Mihai Radu [EMAIL PROTECTED] Critical Mass Labs smiley-3.png Description: PNG image ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] osgShadow::ShadowMap implementation
Hi, The SVN version compiles works very nice (Fedora 6). About the clipping for SM creation; if we could get the shadowers clipped by the main view frustum, and then use the bounding box of this for adjusting the SM camera, it would make a big improvement for SM anti-aliasing. With the current method, adding in a shadow-casting terrain makes the part of SM used close to the main camera very small, therefore very jaggy. On the subject of texturing control, for the simulation at work I wrote a little ShadingHelper, that applies shaders ( with sources taken from lua config files), and applies them according to an [enum] criteria to selected parts of our scene. Right now we are distinguishing between regular 3D objects, particle systems and text (this one has a NULL Program on it). I think this is the beginning for more control for shading in osg, it could be used to delegate the creation and storage of shading programs and uniforms for the rest of the application. Then if below a certain node there's a need for a specific program something like this could be called: ShadingHelper::setShadingProgram((osg::Node*) i_node,ShadingHelper::ShadingProgramType::SHADOWED_TEXTURED); for uniforms I can call something like this: ShadingHelper::setShadingValue((osg::Node*) i_node, (std::string)i_uniformName, class T value); Some ideas on the things a general design should accomplish would be very welcome. Cheers Mihai On Mon, 2007-02-19 at 13:04 -0500, Martin Tapp wrote: Hi, I think that going for the alternative of querying the scene is a great way to go. This way, we would be able to construct various shaders dynamically based on the requirements of scene nodes. Some shaders would to shadow and some wouldn't. This would also help to have full scene shaders which go down to the geometry level for specific effects. The big problem is the management of such a shader interface since we can only have one main method, and determining the requirements of the scene can be complex/slow is not done well. (just my 2 cents!) Regards, Martin __ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, February 19, 2007 12:43 PM To: osg users Subject: Re: [osg-users] osgShadow::ShadowMap implementation Hi Mihai, On 2/19/07, Mihai Radu [EMAIL PROTECTED] wrote: Saw it :) Had to wait for a couple of fixes while I was building, but now [ rev. 6238 ] it works very nicely. So does the latest SVN version compile fine? If not point me at the errors. I have done this before, by using a bool Uniform to control the texturing. On the first implementation, I had a flag when adding to the scenegraph. As an improvement, I was thinking of testing the models for texturing ( at addition or update ) , I'm not sure if the steps below are sufficient : Visit the model, test each Drawable for StateSet-textureAttribute and set the Uniform accordingly Any suggestions for some code that does something similar wold be very welcome. I was thinking about having a uniform too, or simply a default texture to inherit. The other alternative is to go an query how the scene graph is set up and apply different shaders. This starts to get rather intrusive. This should be interesting, and very close to PSSM for 1 light. It should be relatively straight forward - just multiple cameras, and multiple textures, and different shaders to cope with the different needs. When using spotlights this is much easier, as the spot's parameters can be used. I have a few thoughts on creating convex hulls around the shadow casting model, then clipping this by a frustum created by enclosing the light position with the view frustum. One could add in spot light cone into this clipping as well. Then once you have your tightest bound convex hull you can estimate the best fit projection required to capture it. I think there are a couple of names for different implementations of this [ from GpuGems 1 ShaderX4 ]: Perspective Shadow Maps [Stamminger02] Light Space Perspective Shadow Maps [Wimmer04] Sounds about right. Perspective Shadow Maps title is a bit misleading as a title as the tex gen is perspective based when you have a position light anyway, not even sure Light Space Perspective Shadow Maps is very appropriate either... Bias for the PolygonOffset and bias for SM look-up come to mind. Feel free to add this methods to osgShadow. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman
Re: [osg-users] osgShadow::ShadowMap implementation
Hi Robert,
Thanks again for getting SM started.
While playing around with the example, I noticed that if using
--directionalLight, the code to re-calculate the RTT frustum would
not do it's job( lightpos[3] == 0.0), for now I included a small patch
to the example that cheats a bit by setting lightpos[3] = 1.0f in this case.
Cheers
Mihai
Robert Osfield wrote:
On 2/19/07, *Mihai Radu* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
The SVN version compiles works very nice (Fedora 6).
Thanks for the feedback.
About the clipping for SM creation; if we could get the shadowers
clipped by the main view frustum, and then use the bounding box of
this for adjusting the SM camera, it would make a big improvement
for SM anti-aliasing. With the current method, adding in a
shadow-casting terrain makes the part of SM used close to the main
camera very small, therefore very jaggy.
To make ShadowMap and ShadowTexture more usable in real apps we have
implement better set up of the RTT cameras/shadow texture so that its
view dependent. The funding I have for osgShadow doesn't encompass
this though, its focused on ShadowVolume so this is where I'll be
spending my efforts so I'll have to come back to ShadowMap later.
In March I'll be doing some work on view dependent OverlayNode, and
this will require similiar view frustum constrained RTT set up, so
once I've written this we should be able to reuse the various utility
classes that I put together in ShadowMap and ShadowTexture.
On the subject of texturing control, for the simulation at work I
wrote a little ShadingHelper, that applies shaders ( with
sources taken from lua config files), and applies them according
to an [enum] criteria to selected parts of our scene. Right now we
are distinguishing between regular 3D objects, particle systems
and text (this one has a NULL Program on it).
I think this is the beginning for more control for shading in osg,
it could be used to delegate the creation and storage of shading
programs and uniforms for the rest of the application. Then if
below a certain node there's a need for a specific program
something like this could be called:
ShadingHelper::setShadingProgram((osg::Node*)
i_node,ShadingHelper::ShadingProgramType::SHADOWED_TEXTURED);
for uniforms I can call something like this:
ShadingHelper::setShadingValue((osg::Node*) i_node,
(std::string)i_uniformName, class T value);
Some ideas on the things a general design should accomplish would
be very welcome.
I don't really have any ideas on this topic off the top of my head,
and certainly needs a clear head to think about so I'll have defer my
contributions on such topics till my working life settles down a bit
more .i.e less 12 hours days...
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Index: ../examples/osgshadow/osgshadow.cpp
===
--- ../examples/osgshadow/osgshadow.cpp (revision 6239)
+++ ../examples/osgshadow/osgshadow.cpp (working copy)
@@ -567,7 +567,7 @@
}
else
{
-lightpos.set(0.5f,0.25f,0.8f,0.0f);
+lightpos.set(0.5f,0.25f,10.8f,1.0f);
}
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] osgShadow::ShadowMap implementation
Hi Robert, I'm having problems even allowing for a static light, so I don't need to grab the updated position. How do I add the PRE_RENDER [ to RTT ] Camera ? Adding a Group as the SceneData, then adding ShadowedScene and Camera does not work : osg::ref_ptrosgShadow::ShadowedScene shadowedScene = new osgShadow::ShadowedScene; #if 0 osg::ref_ptrosgShadow::ShadowVolume shadowVolume = new osgShadow::ShadowVolume; shadowedScene-setShadowTechnique(shadowVolume.get()); shadowVolume-setDynamicShadowVolumes(updateLightPosition); #else osg::ref_ptrosgShadow::ShadowMap shadowMap = new osgShadow::ShadowMap; shadowedScene-setShadowTechnique(shadowMap.get()); //shadowedScene-addChild(shadowMap-getCamera()); #endif osg::ref_ptrosg::LightSource ls = new osg::LightSource; ls-getLight()-setPosition(lightpos); shadowedScene-addChild(model.get()); shadowedScene-addChild(ls.get()); osg::ref_ptrosg::Group grp = new osg::Group; grp-addChild(shadowedScene.get()); grp-addChild(shadowMap-getCamera()); viewer.setSceneData(grp.get()); Any help appreciated Mihai On Tue, 2007-02-13 at 22:11 +, Robert Osfield wrote: Hu Mihai, To get the position of the light source you do what the osgShadow::ShadowVolume technique does and let the traversal happen for the scene then get the PositionalStateContainer from the RenderStage that the cull traversal has populated, then build the view and projection matrix according to this position. Robert. On 2/13/07, Mihai Radu [EMAIL PROTECTED] wrote: Hello Robert, I've been trying to implement osgShadow::ShadowMap, using the old osgdepthshadow as a starting point. I am attaching ShadowMap[.cpp] and testShadow.cpp[ based on osgshadow example ]. I hit a bit of a wall, and here are some of the points I'm not very clear on: 1. there is a Camera[PRE_RENDER] to RTT the depthMap, it's viewFrustum needs to be updated according to the light, but where is the appropriate call-back for it in the Update or in the Cull traversals ?? 2. same for TexGenNode for applying the said depthMap 3. how do I add the Camera to the rendering ? (if I add it to ShadowedScene, there is a loop, since the sceneData of the Camera is ShadowedScene) 4. where is appropriate to add the TexGenNode (ShadowedScene seems like the candidate) ? Right now I've turned off the depth comparing on the depthMap to see what is happening, and all I get is a black rectangle. I've looked through the code for ShadowVolume, and I see you do some magic with the renderBins in Cull traversal, but I can't quite figure if I need to do something similar (I guess because I don't quite get what is happening there :) I would really like to have this going, then I could use the nodeKit with the application we are working on ( I'll have to back-port it to osg 1.2, but that's not a big deal if I exclude ShadowVolume technique). Regards Mihai Radu cm-labs.com -- Mihai Radu [EMAIL PROTECTED] Critical Mass Labs ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgProducer Viewer window disappears
Hi, I have seen this kind of behavior with our application based on osgProducer, it only appears when there is quite a bit of mouse activity. Robert Osfield wrote: Hi Julian, I haven't heard of windows just disappearing but perhaps others in the community will have seen it. A few questions. Which platform are you working under? WinXP sp2 [current patches] What hardware? Nvidia 7900 GT 256 Mb pciE, drivers # 93.71 What version of the OSG? osg 1.2 Is this a recent problem? only noticed in the latest app, that uses osg 1.2 Does the application crash at all? The application is WxWidgets based, and it creates osgProducer thread[s] The application does not crash immediatelly, next time it will happen, I will try to restart the 3D window. If its a hang have you been able to stop execution in a debugger to find out where its hung? Next crash I'll try to get some stack trace. Robert. Hope this helps Mihai Radu On 2/14/07, Julian Looser [EMAIL PROTECTED] wrote: Hello, I realise there has been a lot of development recently on new viewer classes for OSG, however for my project I am still using osgProducer::Viewer. I am working on an interface evaluation that is nearly complete. I have developed a user interface with OSG but I have encountered a serious problem. The viewer window occasionally completely disappears leaving only the console window active. The program is still running (can see it in Task Manager) but the window is gone. I've noted that this happens only when I am doing a lot of mouse input processing. I am using my own subclass of osgGA::GUIEventHandler to process input events. When I get a mouse move/push/release event I use the viewer.computeIntersections(x,y,hits) function to work out which interface component the user is interacting with. Right now I don't know where the problem lies, so this is a broad question of whether anyone else has had this sort of thing happen. If nobody has any ideas then I will try to track it further and form some more detailed questions. Thanks in advance, Julian. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgShadow::ShadowMap implementation
Hello Robert,
I've been trying to implement osgShadow::ShadowMap, using the old
osgdepthshadow as a starting point.
I am attaching ShadowMap[.cpp] and testShadow.cpp[ based on osgshadow
example ].
I hit a bit of a wall, and here are some of the points I'm not very
clear on:
1. there is a Camera[PRE_RENDER] to RTT the depthMap, it's viewFrustum
needs to be updated according to the light, but where is the appropriate
call-back for it in the Update or in the Cull traversals ??
2. same for TexGenNode for applying the said depthMap
3. how do I add the Camera to the rendering ? (if I add it to
ShadowedScene, there is a loop, since the sceneData of the Camera is
ShadowedScene)
4. where is appropriate to add the TexGenNode (ShadowedScene seems like
the candidate) ?
Right now I've turned off the depth comparing on the depthMap to see
what is happening, and all I get is a black rectangle.
I've looked through the code for ShadowVolume, and I see you do some
magic with the renderBins in Cull traversal, but I can't quite figure if
I need to do something similar (I guess because I don't quite get what
is happening there :)
I would really like to have this going, then I could use the nodeKit
with the application we are working on ( I'll have to back-port it to
osg 1.2, but that's not a big deal if I exclude ShadowVolume technique).
Regards
Mihai Radu
cm-labs.com
#include osg/ArgumentParser
#include osg/LightModel
#include osg/Depth
#include osg/BlendFunc
#include osg/Camera
#include osg/Stencil
#include osg/StencilTwoSided
#include osg/CullFace
#include osg/Geometry
#include osg/Switch
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/StateSetManipulator
#include osgViewer/Viewer
#include osgViewer/StatsHandler
#include osgShadow/OccluderGeometry
#include osgShadow/ShadowedScene
#include osgShadow/ShadowVolume
#include osgShadow/ShadowMap
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osg/Geode
#include osg/BlendFunc
#include iostream
class ComputeBoundingBoxVisitor : public osg::NodeVisitor
{
public:
ComputeBoundingBoxVisitor():
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN)
{
}
virtual void reset()
{
_matrixStack.clear();
_bb.init();
}
osg::BoundingBox getBoundingBox() { return _bb; }
void getPolytope(osg::Polytope polytope, float margin=0.1) const
{
float delta = _bb.radius()*margin;
polytope.add( osg::Plane(0.0, 0.0, 1.0, -(_bb.zMin()-delta)) );
polytope.add( osg::Plane(0.0, 0.0, -1.0, (_bb.zMax()+delta)) );
polytope.add( osg::Plane(1.0, 0.0, 0.0, -(_bb.xMin()-delta)) );
polytope.add( osg::Plane(-1.0, 0.0, 0.0, (_bb.xMax()+delta)) );
polytope.add( osg::Plane(0.0, 1.0, 0.0, -(_bb.yMin()-delta)) );
polytope.add( osg::Plane(0.0, -1.0, 0.0, (_bb.yMax()+delta)) );
}
void getBase(osg::Polytope polytope, float margin=0.1) const
{
float delta = _bb.radius()*margin;
polytope.add( osg::Plane(0.0, 0.0, 1.0, -(_bb.zMin()-delta)) );
}
void apply(osg::Node node)
{
traverse(node);
}
void apply(osg::Transform transform)
{
osg::Matrix matrix;
if (!_matrixStack.empty()) matrix = _matrixStack.back();
transform.computeLocalToWorldMatrix(matrix,this);
pushMatrix(matrix);
traverse(transform);
popMatrix();
}
void apply(osg::Geode geode)
{
for(unsigned int i=0; igeode.getNumDrawables(); ++i)
{
apply(geode.getDrawable(i));
}
}
void pushMatrix(osg::Matrix matrix)
{
_matrixStack.push_back(matrix);
}
void popMatrix()
{
_matrixStack.pop_back();
}
void apply(osg::Drawable* drawable)
{
if (_matrixStack.empty()) _bb.expandBy(drawable-getBound());
else
{
osg::Matrix matrix = _matrixStack.back();
const osg::BoundingBox dbb = drawable-getBound();
if (dbb.valid())
{
_bb.expandBy(dbb.corner(0) * matrix);
_bb.expandBy(dbb.corner(1) * matrix);
_bb.expandBy(dbb.corner(2) * matrix);
_bb.expandBy(dbb.corner(3) * matrix);
_bb.expandBy(dbb.corner(4) * matrix);
_bb.expandBy(dbb.corner(5) * matrix);
_bb.expandBy(dbb.corner(6) * matrix);
_bb.expandBy(dbb.corner(7) * matrix);
}
}
}
protected:
typedef std::vectorosg::Matrix MatrixStack;
MatrixStack _matrixStack;
osg::BoundingBox_bb;
};
osg::Camera* makeHud(osg
Re: [osg-users] shadows with shaders
I completely agree with Robert that managing shadows needs to be done at (way)more high-level than the card. Shaders come in when looking at the details of applying the shadows, or (before that step) at the creation of the data needed (shadow maps, edge finding[potential with the new geometry shaders]). One slight difficulty I hit when working with shaders, shadows and OSG, is managing the Uniforms used for parameters in the shaders (some need to be applied on per-object basis, but the only link with the GLSL representation that will reside in ShadowTechnique is the name used ) and the Varying used to pass interpolated parameters from Vertex to Pixel stages (this is a bit of hardware restrictions getting in the way when using spotlights in my case). If you have any practical questions, fire away :) Mihai Radu Robert Osfield wrote: Hi Zach, On 2/8/07, Zach Deedler [EMAIL PROTECTED] wrote: Hello osg users/developers, Are there any plans to do shadows using shaders? I know hardware shadowing is supported on newer video cards. Many shadow effects are implemented with shaders, the osgdepthshadow example is based on GLSL. As far as I'm aware hardware shadowing doesn't exist in the form that you are probably hoping for, I don't know of any future plans either. There are various extension to help optimize existing high level shadow routines such as shadow maps and two sided stencil tests, but this are are very low level components. Shadowing will be for a long time something that requires the scene graph to manage at a high level - you need to control the light sources, the occluders and the shadow scene all in special ways. For the hardware to do all what is required will require the hardware to effectively have a high level representation of the scene. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Multiple shaders and RTT
Hi Brian, A couple of pointers that come to mind for your case: 1. to control the rendering order you can use RenderingBin numbering. For pre-render, your best bet is to use negative numbers, with the CameraNode you intend to be first having the lowest RenderBin nr. 2. When you attach the texture as RenderTarget, make sure you can pass the [Texture]object out of that particular function, so you'll be able to use it in the next pass for texturing. Here is a matter of being careful with ref_pointer, if you're using them, so that the texture does not get dereferenced at the end of that call, also it's nice to use the same TextureUnit, I think that will avoid making copies of it. (Of course you'll need to have TexCoords for the quad on the second pass, I assume you set them per-vertex at creation time). Cheers Mihai Radu [EMAIL PROTECTED] wrote: Hi Robert, I understand about reviewing the code. I only included it in case it might prove helpful. Anyway, while I haven't gotten this to work just yet, I have managed to confirm a few things. Separately, both CameraNodes can be added and render their respective textures fine, so I know that they are set up correctly in that regard. I've set up a quad osg::geometry and have added it to the camera node and have associated a texture with it for test purposes. CameraNode1 - quad with test texture | |-- CameraNode2 - cow node attached When I render my final quad using CameraNode1's RTT texture, it correctly displays the rendered textured quad. However, I am assuming that in order to render the quad's texture with CameraNode2's rendered scene, I would need to use the texture associated with CameraNode2's texture that is attached to its FBO for RTT. CameraNode1 - quad with CameraNode2's rendered texture | |-- CameraNode2 - cow node attached When I try this approach, I see a black square. Both camera nodes are set to PRE_RENDER. Thanks, Brian ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] CVS rename of osg::CameraNode - osg::Camera
Hi Robert, It's nice to see that CameraNode [oops osg::Camera from now on ] is being developed, I quite enjoyed using it, however I have some snags that I hit while trying to use it and I would really appreciate some pointers Here are the snags hit while playing a bit with Camera[Node]: 1. When trying to use it as a main render camera(s) for my app, I couldn't because I need to have the option of multiple windows. Here I don't know how to integrate it with osgProducer, RederSurface etc ... 2. I tried to make a 'mounted camera' [ something like a security cam etc... ], have a Camera[Node] attached to the transform of a node in the scene with RELATIVE reference frame, so that I could have a camera that moves with that object without having to do updates through osgGA manipulator. Here there were 2 problems: - if I attach to the above Camera[Node] the entire scene (as in the main scene) to be rendered, I get crashes (I suspect because there's a loop in the SceneGraph, but I'm no sure) - the view from this Camera[Node] is being influenced by manipulations of the main camera, ruining the whole effect Cheers Mihai Radu Robert Osfield wrote: Hi All, I have just checked into CVS a bit more work on the road to the new osgViewer library, as part of this work I have renamed osg::CameraNode to osg::Camera. This change could break the CVS build so please be weary, I've tried to dot all the i's and cross all the t's but there is always I chance I've missed something. Please test and shout if something is amiss and I'll get to it ASAP. The motivation for the name change is the dual role that osg::Camera will have - one also a node in the scene graph for HUD's, RTT and special effects work, and a second role as camera above the scene graph at the viewer/application level - for the later role the osg::CameraNode name is rather out of place. I have left the include/osg/CameraNode header in place with an typedef osg::Camera CameraNode to help out with backwards compatibility. I'll keep this in place for OSG-1.3, but in the longer term will remove this file to keep the overall API clean. Also as part of the new check in are the new osgViewer files, Scene, View, Viewer, CompositeViewer and GraphicsWindowProxy. Now these files are really just placeholders right now and aren't ready to use in any way so hold back from playing with them. In another week or so I'll set to the task of filling their functionality out, and will talk much more extensively about where I'm heading with these classes then. Cheers, Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] NodeMask numbering with multiple cameras
Hi Tristan, since I was interested in checking out osg::Switch, I
reworked your example to get the result you wanted:
1: changed how models got added to have only 1 enabled at start
2: in the main loop, I changed the logic that does the switch, so it's
only called when needed
I think this could be an ok tutorial for osg::Switch, so if people find
it interesting enough we could submit it.
Regards
Mihai
Tristan McMillan wrote:
Hi
Okay the first was a simple error I agree, but even after changing that
too:
Switchg-insertChild(2,model2Node.get());
Switchg-insertChild(1,model1Node.get());
The scene doesn't alternate between the two models for some reason.
It must be crazy friday or something.
Thanks
Tristan
On Fri, 2006-11-17 at 13:51 +, David Spilling wrote:
Firstly, you do this, which I'm sure you don't mean (note the models
you are actually adding).
Switchg-insertChild(2,model2Node.get());
Switchg-insertChild(1,model2Node.get ());
Secondly, you do this, which I'm also sure you don't mean (your temp
counter will flicker between true and false)
if ( counter 1000)
{
counter = 0;
temp = !temp;
}
else
{
counter++;
}
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
#include osg/Group
#include osgDB/ReadFile
#include osgDB/Registry
#include osgProducer/Viewer
int main( int argc, char **argv )
{
osg::Switch *Switchg = new osg::Switch();
osg::ref_ptrosg::Group rootNode = new osg::Group();
//osgDB::FilePathList pathList;
//pathList.push_back(/opt/OpenSceneGraph-Data/models/);
//osgDB::setDataFilePathList(pathList);
osg::ref_ptrosg::Node model1Node = osgDB::readNodeFile(cow.osg);
if (!model1Node)
{
std::cout no model1 std::endl;
abort();
}
osg::ref_ptrosg::Nodemodel2Node = osgDB::readNodeFile(dumptruck.osg);
if( ! model2Node)
{
std::cout no model2Node std::endl;
abort();
}
Switchg-addChild(model1Node.get(),true);
Switchg-addChild(model2Node.get(),false);
std::cout Children: Switchg-getNumChildren()std::endl;
rootNode-addChild(Switchg);
osgProducer::Viewer viewer;
viewer.setUpViewer(osgProducer::Viewer::STANDARD_SETTINGS);
viewer.setSceneData( rootNode.get() );
viewer.realize();
int counter = 0;
bool switchModels = false;
int currentModel = 1;
while( !viewer.done() )
{
viewer.sync();
viewer.update();
if ( counter++ 1000)
{
counter = 0;
switchModels = true;
}
if (switchModels == true )
{
if (currentModel == 1)
{
Switchg-setSingleChildOn(1);
currentModel = 2;
}
else
{
Switchg-setSingleChildOn(0);
currentModel = 1;
}
switchModels = false;
}
std::cout Counter: counter Current child:
currentModel-1 Value: Switchg-getValue(currentModel-1) std::endl;
// fire off the cull and draw traversals of the scene.
viewer.frame();
}
// wait for all cull and draw threads to complete before exit.
viewer.sync();
return 0;
}___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] Re: Fedora Core 4 packages of OSG 1.2
On Tue October 31 2006 09:21, Robert Osfield wrote: On 10/31/06, Robert Osfield [EMAIL PROTECTED] wrote: Hi Don, On 10/31/06, Eric Sokolowsky [EMAIL PROTECTED] wrote: A while back I uploaded some OSG 1.2 packages for Fedora Core 4. Did these ever make it to the download page? I'm afraid not, thanks for the reminder though, I'll need to update them. I'm just looking at the .rpm's on the ftp upload directory: OpenSceneGraph-1.2-2.i386.rpm OpenSceneGraph-debuginfo-1.2-2.i386.rpm OpenSceneGraph-devel-1.2-2.i386.rpm OpenSceneGraph-examples-1.2-2.i386.rpm OpenThreads-1.2-2.i386.rpm OpenThreads-devel-1.2-2.i386.rpm Producer-1.2-2.i386.rpm Producer-devel-1.2-2.i386.rpm I was a bit suprised to see the OpenThreads and Producer versions tagged with the OSG release number rather than their own release numbers. Would renaming them be sufficient? Would they still work? Robert. The version numbers are usually pulled out of the .spec file from the source rpm (.srpm). Just renaming the .rpm files will not change the way that rpm will try to solve dependencies when they are installed. If Eric can post the .spec file(s) or the source rpm, and assuming they are generated out of the sources on the websile, I can fix the version numbers and regenerate a set for Fedora5 (what I currently have). The .spec files can then be used to re-generate for other red-hat versions. -- Mihai Radu cm-labs.com ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Re: NVPerfSDK for Linux
Thanks for the heads-up. I was looking into doing some performance testing, but having to reboot in win made it one of those 'I'll get to it tommorow' kind of jobs :) -- Mihai Radu cm-labs.com On Fri October 20 2006 08:10, Donald Tidrow wrote: There are finally official versions of the NVPerfSDK available for Linux, both 32-bit and 64-bit versions. You have to install an special instrumented driver, but it provides access to performance counters available on the latest NVIDIA graphics cards (GeForce 6xxx and 7xxx cards primarily, though there is some limited support in GeForceFX cards). Details and downloads here: http://developer.nvidia.com/object/nvperfkit_home.html Don ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Multiple pass rendering problem
I am trying to add osgDepthShadow code - uses CameraNode with PRE_RENDER to fbo, then adds this node to the scene to an existing osg application - uses Producer::CameraConfig and creates the config for possibly multiple windows by creating a set of Producer::Camera each with Producer::RenderSurface and Producer::InputArea and I think there's a problem in that the CameraNode does not seem to be rendering. Can these 2 set-ups for the cameras be mixed, or do I need to use only CameraNodes or only Producer::Camera ? -- Mihai Radu cm-labs.com ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Re: Multiple pass rendering problem
To answer my own question: I was not adding the CameraNode to the scenegraph, so it was not getting rendered -- DUH The question is still valid: how does a PRE_RENDER or NESTED_RENDER CameraNode behaves in a multiple-camera (Producer::Camera) application ? Thanks -- Mihai Radu cm-labs.com On Fri October 13 2006 13:04, Mihai Radu wrote: I am trying to add osgDepthShadow code - uses CameraNode with PRE_RENDER to fbo, then adds this node to the scene to an existing osg application - uses Producer::CameraConfig and creates the config for possibly multiple windows by creating a set of Producer::Camera each with Producer::RenderSurface and Producer::InputArea and I think there's a problem in that the CameraNode does not seem to be rendering. Can these 2 set-ups for the cameras be mixed, or do I need to use only CameraNodes or only Producer::Camera ? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgShadow wiki page
I've added a section for regular depth-shadows and uploaded a re-worked version of the example.
Just realized I forgot to add a main program, so here's how to use the classes:
// initial set-up
mShadow = new osg::osgSceneManager;
if (arguments.read(-fixed))
{
mShadow-getShadowUtil()-setExtensionType(osg::osgDepthShadow::shadowExtensionFixedFunct);
}
mShadow-initializeSceneDefaults();
// add things to scene like this
// inShadow does nothing for now, shadows get applied to everything
addToScene(osg::Node* node,bool occluder=true, bool inShadow=true);
scene = mShadow-getSceneRootInstance().get();
// standard from here on:
viewer-setSceneData(scene);
I hope this helps pushing the shadow library a bit forward.
--
Mihai Radu
cm-labs.com
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] Re: Texturing an OSG model
On Thu October 12 2006 01:53, Schmidt, Jerran (Student) wrote:
Hi,
I have been working with OSG briefly and was wondering:
I have a model that I have exported to .osg format, this model is a wall
with named panels on it. They are exported with a default bitmap
textures so looking at the osg file yeilds:
MatrixTransform {
...
name panel1
...
Geode {
...
textureUnit 0 {
...
Texture2D {
...
file images\default.tga
...
If I load a osg::glTexture2D, how do I load this to a particular panel
on the model at runtime?
I have loaded the models like:
osg::Node *modelNode;
modelNode = osgDB::readNodeFile( argv[1] );
Sorry about the pseudo-code, but the process is:
The skeleton would be this:
- find the panel you're looking for
start with modelNode
check all children (recursive) for the name of the panel
- add the texture2D to it
mState = mNode-getOrSetStateSet()
mState- ( ... activate the new texture [maybe texUnit 1 ] ... )
mState- ( . set state ti OVERRIDE / PROTECTED )
See this site for more
Thanks!
Jerran Schmidt
Command Control Division (C2D)
Defence Science and Technology Organisation (DSTO)
PO Box 1500 Edinburgh SA 5111
Office: 2.D.31, 205 LABS
Phone: (08) 8259 7554
Fax: (08) 8259 5624
Email: [EMAIL PROTECTED]
IMPORTANT: This email remains the property of the Australian Defence
Organisation and is subject to section 70 of the CRIMES ACT 1914. If
you have received this email in error, you are requested to notify the
sender and delete the email.
--
Mihai Radu
cm-labs.com
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] Re: Texturing an OSG model
Oops ... Here's a very good site with the kind of code you want: http://www.nps.navy.mil/cs/sullivan/osgtutorials/ On Thu October 12 2006 01:53, Schmidt, Jerran (Student) wrote: Hi, I have been working with OSG briefly and was wondering: I have a model that I have exported to .osg format, this model is a wall with named panels on it. They are exported with a default bitmap textures so looking at the osg file yeilds: -- Mihai Radu cm-labs.com ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] CameraNode PIXEL_BUFFER/-_RTT fails for Release builds under WIndows
On Thursday 21 September 2006 08:41, Stephan Maximilian Huber wrote: I know, that the ATI-driver for my MacBookPro under windows is crappy, and does not support PixelBufferObjects so the CameraNode falls back to pbuffers, but why do they work onyl in debug-mode? Thanks in advance, Stephan You can always install the newest driver from ATI on the MBp, there is nothing custom about the GPU in it. Hope this helps narrow your debugging. -- Mihai Radu cm-labs.com ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Parallel-Split Shadow Map with osg [PSSM]
Hi Adrian, I'm currently working on depthShadow code, but not (yet :) partitioned, so I'm dealing with similar issues. I took a quick look @ the code you posted, and seems to be working ok. What kind of help did you have in mind ? -- Mihai Radu cm-labs.com On Monday 18 September 2006 10:48, Robert Osfield wrote: Hi Adrian, I don't have time to dabble right now, but pehaps others do. Could you provide a link to further information on the algorithm you are using, also set up a page for this work on the community section of the wiki under the NodeKit seftion, this way you can update the source and screenshots etc without needing to send everything into the list. Cheers, Robert. On 9/18/06, Adrian Egli [EMAIL PROTECTED] wrote: hi i am currently implementing PSSM shadowing technic for osg. who likes to help me. try out the latest state of the implementation. /adegli ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] problem with 1.2 and openflight models on mac
I have been installing the frameworks and plugins in: ~/Library/Frameworks ~/Library/Frameworks/PlugIns (not sure about the capitalization here) and everything is getting picked-up properly. -- Mihai Radu cm-labs.com On Wednesday 13 September 2006 22:11, E. Wing wrote: As far as I know, nothing was supposed to change wrt the plugins locations. I just tested the freetype plugin and it stills seems to be picked up from /Library/Applications Support/OpenSceneGraph/PlugIns If you are on a case sensitive file system, make sure the 'I' in PlugIns is captialized. But I don't think it should matter if you're not. Maybe it is something specific to the OpenFlight plugin? Or maybe something changed in osgViewer? -Eric ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] RenderBin Error
Hi, I'm getting the same errors with 1.2 while playing with depth-shadow FBO. It shows up when accessing the texture set up as GL_DEPTH_COMPONENT with a Texture2D sampler and texture2D(unit, gl_coords[0]) function. The error does not show up if I use Shadow2D sampler and shadow2D() access function. I suspect that the compiler for GLSL is more strict about matching the samplers used with the declared format of the texture. Check for any inconsistencies between the shaders and application in regards with texture access. It would be nice if osg::setNotifyLevel(); could enable more information from the GLSL compiler to be able to trace more of these errors, or just have more info coming in from it to help with shader development. Hope this helps. -- Mihai Radu cm-labs.com On Wednesday 13 September 2006 22:07, [EMAIL PROTECTED] wrote: I upgraded to OSG 1.2 today. I am now consistently getting the following error message whenever I use FBO's: Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) I would get this occasionally (1% of the time) with v1.1 but now I am getting it EVERY time with v1.2. I assume there is something that I am doing wrong, but as I see no problems with the rendered scene, I was wondering what types of operations could be causing this or what I could do to attempt to track it down. Particularly, what operations would cause an error on the FBO that wouldn't cause an error for a normally rendered scene? Were there any changes to the RenderBin which would cause v1.2 to catch an error that v1.1 would not consistently catch? Any help would be appreciated! Thanks! - Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OpenSceneGraph-1.2 Release prep
For me setting this in my environment: setenv OSG_TEXT_INCREMENTAL_SUBLOADING OFF does take care of the font rendering related crashes. Since it's OSX, I have it both in my .bash_profile for console apps, and in ~/.MacOS/environment.plist In other poking around I've done, osgprecipitation runs so slow, I first thought it had frozen. But it responded after about a minute to escaping out of the program. Mac Book Pro osx 10.4.7 i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363) -- Mihai Radu cm-labs.com On Monday 11 September 2006 10:01, Robert Osfield wrote: On 9/11/06, Robert Osfield [EMAIL PROTECTED] wrote: This leaves the reported build problems under OSX with certain combinationes of gcc and the OS version. I couldn't see any final resolution to the thread that started on thelist but ended up off it, so I'll bring it back onto the list now, could OSX'rs test out and try to find some resolution to what #ifdef combination in include/osg/Math will do the trick. Has anyone made an more progress towards resolving these problems? I'll wait another hour, then go ahead a make 1.-2-rc3. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Fragment shader question - somewhat off topic - sorry
I am quite interested in the management of the texture units also, since I'm doing work with depthshadows, and I have to take into account that the objects that get shadowed might have textures enabled on them. This becomes even more complicated if I consider adding bump-mapping or normal mapping to some of the objects. Therefore a variable number of texture units can be active. Currently, osgdepthshadow uses an uniform variable, I think it's called 'unit', to choose between fragment shaders that apply shadow for a textured or untextured object. In this implementation, if the scene uses textures, the depth-map for the shadow is created on texUnit 1, using texUnit 0 for textures; otherwise only texUnit 0 is used for generatig the depth map. Roger, you can look at the code in osgdephshadow.cpp for the code. The parts that I was talking about are in main() and in the shader code. Is there any place to start looking for management of textures and texture units ? I'm not sure if this would be at the viewer level or at the scenegraph level. What would make me very happy would be something that could allow me to manage not just the texture objects within OSG, but also to have the ability to controll where they are stored also, in GPU ram or in system memory. -- Mihai Radu cm-labs.com On Monday 11 September 2006 13:12, Mike Weiblen wrote: Hi Roger, Roger James wrote: I apologise in advance for this being somewhat off topic, but this was the best place I could think of for a quick answer. Q. In an OpenGL fragment shader program, how do I find out which texture units are currently active? If by active, you mean they're enabled for fixed-functionality texturing, then no, there is not a built-in GLSL uniform to query the fixed-functionality enable state of texture units. The reason I ask this is that I am trying to add a procedural texture to part of my scene graph. Other built in functionality texture units may well also be active at this point. Because the fragment shader replaces all the built in texture processing I need to know whether to apply these texture within the shader as well. Your app will need to convey that information via uniforms. The fragment shader function texture2D seems to return vec4(0,0,0,0) when no texture is assigned, but this does not seem to be documented. So can I rely on it? I would not, unless the Spec clearly defined that behavior. Cheers -- mew ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Mihai Radu cm-labs.com ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
