Hi Robert,
Thanks for the reply.
So the proper construction of the set of gl_EyePlaneX planes would be:
InvMVL * ProjL * osg::Matrix::translate(1.0,1.0,1.0) *
osg::Matrix::scale(0.5,0.5,0.5)
with InvMVL == Inverse ModelView matrix for shadow camera and ProjL ==
Projection matrix for shadow
Hi,
I've been working on updating our shaders to remove the deprecated built-ins.
I've gotten stuck on the gl_EyePlanes as used to compute projected shadow
texture coordinates as follows (same convention as osg-generated shadow
shaders):
Code:
gl_TexCoord[shadowTextureUnit0].s = dot(
Hi All,
I'm looking at extending the VDSM functionality to write some extra info to
additional RTs. So far, everything is working fine except the fact that
fragments outside of the shadowed area of the shadow map aren't sent to the
shader.
This makes sense, as the rest of the non-casting
Hi Robert,
I checked the svn/trunk last week and as you said the clipping problem seems to
have been resolved.
After exploring your new VDSM implementation further, it seems that there is a
bug with the ReceivesShadowTraversalMask (or I am missing something). If I
turn off this mask bit the
Hi Robert,
This is a super-delayed follow-up but I've finally circled back around to this
issue.
Using the standard osgshadow example I can reproduce the general problem I'm
having (shadows being clipped prior to the edge of the screen) by running with
the following parameters:
osgshadow
Hi Robert,
Thanks for the quick reply.
I am using 3.1.1 with the hopes of remaining somewhat stable. ;)
Perhaps I should try the svn/trunk version.
Attached is the animation path that shows the clipping on my installation. The
forum would not allow the *.path extension so I change it to .txt
Hi Robert,
I haven't been able to reproduce my specific problem with the osgshadow
example, but I have been able to reproduce all kinds of weird clipping planes.
Just none that are resolved by commenting out the aforementioned section.
For instance, if I set the default light direction in the
Hi Robert,
Thanks for the suggestion! VDSM is nice and concise - nice work!
But unfortunately I still get the same clipping problem with it, so I'm sure
it's something wrong on my end. I'll keep plugging away and see what I can come
up with.
Thanks again,
Garrett
...
--
Robert,
Attached are two screen shots. 'shadow_before' is the base state with a box
casting a perfectly fine shadow. 'shadow_after' is where I have rotated the
camera such that the box has moved out of view to the right. In this image you
can see another clipping edge beginning at the bottom
Hi Wojtek,
Thanks for replying.
The projection matrix at the points you mention matches what it is in my main
app. I also set do_not_compute for the near/far planes on the main camera but
didn't find any difference.
If I understand the clipping correctly, it's just a polytope representing
Hi,
I'm working with the osgShadow LiSPSM implementation as that seems to be the
one that people have had the most success with. The shadows are great, but are
being clipped vertically as the shadowing object moves near the left or right
edge of the window.
I've seen similar issues in other
That was it! Thanks so much for the help Wojtek!
...
Thank you!
Cheers,
Garrett
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=48307#48307
___
osg-users mailing list
Hi,
I currently have an osg scene running that uses hardware skinning (via
osgAnimation) to animate some character models. Using these models as as the
shadow casters and a ground plane as the shadow receiver I've been trying
to test the various osgShadow implementations.
My issue is this:
Hi Cedric,
Thanks for the response and sorry for the bother!
I think that you are correct that my problem is with setting up
invBindMatrixInSkeletonSpace. As I mentioned in an earlier post, adding a
rotation offset to this matrix seems to make the skin geometry all screwy.
Without being able
More investigation, still not much clearer. I'm hoping with a more concrete
example someone can tell me what I'm missing...
My main issue is how to change the coordinate system of a bone within the
skeleton hierarchy. This could be done previously by just modifying the
rotation of the bones
Hi,
I'm having a mouse cursor/ windowing issue that I'm hoping someone has run
across. I'm changing the mouse cursor via the setCursor() method copied below
in my Windows App's preframe function. It works, but the cursor doesn't
actually redraw without some sort of mouse input.
I can't seem
Hi J-S,
I think you're original suspicion is probably right. It looks like the C
runtime libraries from VS2005 are still being loaded, though I can't figure out
where from... Hopefully once I resolve that the problem will go away. I will
update after that. Thanks for advice!
--Garrett
Hi,
I recently moved from VS2005 to VS2010 and all of my MFC based projects now die
with the same memory access error in memcpy_s() when setting up the
manipulator. The osgviewerMFC example experiences the same issue. Has anyone
gotten an osg-MFC example compiled through VS2010 yet?
It seems
Hi J-S,
Thanks for the reply. I also am using OSG with VS2010 on other projects with no
problems. The only time I encounter this issue is when running an MFC based OSG
app compiled with VS2010.
As you suggested I double checked to be sure that I am compiling with the
correct library versions
Hi Cedric,
Thanks much, that was very helpful for debugging. Everything is working now.
The problem ended up being that actions added using AddActionAt(...) to add
actions at the zero frame. They seemed to be skipped so that the action is
never activated. If I added a slight amount to the
Hi,
I was wondering if Cedric or anyone else has gotten the
TimelineAnimationManager to work with skinned animations (RigGeometry -
hardware or software)? I am trying to port my functional BasicAnimationManager
implementation over to TimelineAnimationManager as shown in the
Hi,
I'm currently working on adding shadows to my scene using
osgShadow::StandardShadowMap. Everything is working fine except for my biped
animations (using osgAnimation and hardware implementation of RigGeometry). The
problem is that a shadow map is not being generated for geometry shadowed
I've seen many posts on the forum (as well as the QSG) that say that setting
'setDataVariance(osg::Object::DYNAMIC)' will stop nodes from being optimized
out of the graph.
I've had several instances where this doesn't seem to be true. Most recently, I
have an osgFX::BumpMapping node that is
Hi,
I'm trying out osgShadow and have encountered various problems that I can't
seem to find mentioned in the forum. The biggest one is shown in the attached
jpg. The shadow is rendered below the object (using SoftShadow), but it has a
bunch of light un-shadowed pixels appearing in the middle.
Cedric,
Thanks for making the changes. I had made them locally as well, but was too
slow with getting them to you - sorry! It works well for me now.
Thanks again,
Jamie
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=26195#26195
It sounds like the change is worthwhile, so I'd be glad to make the changes. I
will coordinate with Cedric.
Thanks,
Jamie
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=26065#26065
___
osg-users
Hi Roland,
Thanks much, that was exactly what I was looking for. I was missing the fact
that a different channel would be required for each animated transition. Thanks
for the help!
--jamie
--
Read this topic online here:
Hi,
I noticed that osgAnimation::animation::update uses floating point precision
rather than double for it's calculations.
Was there a reason for this choice? I'm experiencing a noticeable loss of
precision in my animations at this point.
Thanks for your help,
Jamie
--
Read
Michael,
Thanks for the reply. I figured that was probably the reason, but wanted to
check since it seems that other plugins (like osgParticle) carry the double
precision through the update functions.
I think all of the update functions would have to be changed over to fix my
problem, but it
Hi,
To Cedric - or anyone else well versed with MorphGeometry in osgAnimation:
I'm attempting to implement a coordinate interpolator. Basically, animating a
mesh with vertex-independent transforms. It seems to me that MorphGeometry
should accomplish this, but after digging through the
Hi Cedric,
I was able to fix the issue by changing the way in which I was loading vertex
data. My native data is X3D (similar to VRML), so I was loading the geometry
using the method in the existing OSG VRML import plugin. I replaced this method
with the data loading used in the osgskinning
Sorry, the texture thing was just me being dumb! Normals still don't work, but
I'll work it out.
Thanks for all of your help.
I guess there is still an issue with the plugin not liking vertices loaded with
a different method. Sorry I couldn't come up with a small example. I'll let you
know if
Paul,
Don't need anybody to debug my code - just thought I would ping the community
and see if anybody had encountered a similar issue with migration.
For future reference, the issue was the 'glReadBuffer(_readBuffer);' call on
line 907 of RenderStage.cpp being called with a null buffer. I
Hi,
I'm looking for a clarification from Cedric (or anyone else experienced with
osgAnimation) on the correct way to set up the data structures for the hardware
skinning implementation.
Integrating the hardware skinning example with my code works fine with example
files like nathan.osg or any
Hi Robert,
Yes, I experienced the same issue using example data files as well (cow.osg).
I'd be glad to help track down the root issue. What do you need from me?
Cheers,
Garrett
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=24861#24861
Hi Cedric,
As it is right now the code is part of a larger plugin, so it's not exactly a
small example. I'll try to put something smaller together.
Generally speaking though, should it work to use the RigGeometry setup in the
software skinning example and just add the
Hi Cedric,
My data is not in a natively supported format, so it probably wouldn't do much
good for me to send it to you.
It will probably take me longer to decouple that section from the app than it
is worth, so I will just try and debug it further and let you know what I find.
I'm just
Paul,
Yep, exact same system with the same hardware and the same application/models.
The only difference is compiling with 2.8.2 libraries vs. 2.9.6.
I will try your suggestions and report back.
Thanks for the help,
Garrett
--
Read this topic online here:
Ok,
When loading cow.osg I experience the same problems described above. Works fine
when my app is compiled with osg 2.8.2, warning message and no visible geometry
when using v. 2.9.6.
When viewing an .osg version of my test plane, there don't seem to be any
special GL features being used. In
Hi,
I recently attempted migrating my application from 2.8.2 to 2.9.6. Everything
seems to build fine, but on running my app with even a simple plane as the
geometry I get the warning: Warning: detected OpenGL error 'invalid enumerant'
at after RenderBin::draw(..) and nothing renders. This
40 matches
Mail list logo
