Wojciech Lewandowski wrote:
> Hi Roger,
>
> During work on inclusion ViewDependentShadows into osgShadow I was
> dealing with similar problem. Certain architectures allow to use
> integer unifrom as gl_TexCoord index but others do not. After few
> different approaches I ended
Hi All,
I once again checked operator precedence to be sure. == operator has higher
precedence than bitwise &. So it looks like parentheses are needed.
Cheers,
Wojtek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Bob Kuehne
Sent: Friday, October 03, 2008
Thanks,
I will try to fix these. As soon as possible.
Cheers,
Wojtek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Roger James
Sent: Saturday, October 04, 2008 9:34 PM
To: OpenSceneGraph Users
Subject: [osg-users] Compile errors in SVN head shadow code w
Adrian,
I am afraid I don't understand what you want to do. Could you provide bit more
explicit explanation ? At higher level of abstraction using LispSM with PSSM
should be possible but I am not that familiar with PSSM implementations to
judge whether it is easy or difficult task to merge two
,
Wojtek
- Original Message -
From: Roger James
To: OpenSceneGraph Users
Sent: Monday, October 06, 2008 12:05 PM
Subject: Re: [osg-users] Compile errors in SVN head shadow codewith
floatmatrices
Robert Osfield wrote:
On Sat, Oct 4, 2008 at 9:40 PM, Wojciech Lewandowski
-submissions about this.
Roger
Wojciech Lewandowski wrote:
Thanks, Robert
Roger, I have modified the code so that it explicitly uses Matrixd in
problermatic cases. So in practice there are no compilation errors, but shadows
are still computed using doubles. I would not risk using
ar_n
[near_0, far_0][near_1=far_0,far_1] [far_1,...] [far_n-1,far_n = far_frustum]
would this be easy to do? multiple shadow technic nodes in one scene to get
such maps.
/adrian
2008/10/6 Wojciech Lewandowski <[EMAIL PROTECTED]>
Adrian,
I am afraid I don't understan
Chris,
Please read following page, until final conclusion:
http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
So if you have gone to the conclusion you should now understand why
computeNearFar is added to OSG. It simply allows to better utilize depth
buffer range. Compute NearFar using
Hi Guys,
Nope, receivesShadowMask is generally ignored in ViewDependentShadows.
Exception in MinimaDrawBoundsShadowMap but there it is used only to
approximate shadow volume which is later additionaly refined.
Problem is that implementing receiveShadowMask without messing with
shaders/and un
J-S, Roger,
I am writing for purely formal reasons. It would be rude to not anwser to
your posts. But J-S actually said all I wanted to say. So I have nothing
more to add. Thanks for discussion guys ;-)
Cheers,
Wojtek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Hi Roger,
I think I have it somewhere on my machine at work. Fortunately for me and
unfortunately for you, weekend has come and I may be able to get there and
send this on monday. Let me know if you are still interested.
Cheers,
Wojtek
-Original Message-
From: [EMAIL PROTECTED]
[mailt
Hi David, J-S
As usual, Great thanks to J-S for doing my work ;-) But I would like to
clarify the blending issue you mentioned.
In the case where the objects that are casting shadows have expensive
fragment shaders, I would prefer to turn these shaders off so that we
just get a quick depth o
Hi J-S,
No, they won't be solid. As they are not solid in for trees drawn in
island scene. But you have to use alpha ref. On the other hand if your
transparency does not use alpha ref and sets Z-values it will still be
solid even if color buffer would end transparent.
Alpha ref? What's that?
. See the
* OpenSceneGraph Public License for more details.
*
* ViewDependentShadow codes Copyright (C) 2008 Wojciech Lewandowski
* Thanks to to my company http://www.ai.com.pl for allowing me free this work.
*/
#include
#include
#include
#include
#include
#include
#include
#inclu
Hi J-S,
I have sent proposed tweaks for submission.
I think your observations prove that AlphaFunc is activated by Transparent
bin. IMHO safest way with dealing with AlphaFunc/AlphaTest is to activate it
explicitly as a node state attribute whenever BLEND is activated or
TransparentBin is sel
Hi J-S,
It looks like we are in sort of counter-phase.You convinced me to your
arguments in the same time as I convinced you to mine ;-)
However, I've confirmed that disabling the renderbin override is not
necessary if I put an AlphaFunc on my root node, so I'd also be happy with
the status
J-S,
>> I suppose that single overriden render bin with AlphaFunc/AlphaTest
>> turned only when needed should be faster in theory. Other options turn
>> AlphaFunce even when not needed. But in practice I doubt difference will
>> be noticable.
>>
>> Even though you managed to activate AlphaFunc, I
J-S,
I agree. I will make proposed changes and resubmit. I will do it tomorrow.
Cheers,
Wojtek
-Original Message-
From: Jean-Sébastien Guay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2008 10:21 PM
To: [EMAIL PROTECTED]; OpenSceneGraph Users
Subject: Re: [osg-users] Advice on
J-S and All,
After a sleep I have taken another look at the subject and I would like to
propose other approach:
In general I doubt I will be able to foresee all types of problems and doubt
I could add flags to suppress all responsible pieces of code. On the other
hand all such problems could b
Hi J-S,
Ok, then lets postpone any changes to the moment we hear additional requests
from others. Once you managed to solve your blending issue this discussion
seems purely academic. Lets wait for some practical problems to appear. I
think this is actually best choice. With every piece we add,
Roger,
I had similar dilemma at some point. I was thinking about overridding cull
visitor but had problem how to substitute original cull visitor with my class
in the middle of cull traversal. Finally I adopted other approach. Once Cull
Visitor traverses the scene all drawbles land in render bi
Hi J-S,
Ok, then lets postpone any changes to the moment we hear additional
requests from others. Once you managed to solve your blending issue this
discussion seems purely academic. Lets wait for some practical problems
to appear. I think this is actually best choice. With every piece we add,
Hi,
Yep. I have not tested latest drivers, but 2 earlier versions: 177.92 &
178.13 were ok as well. Unfortunately Nvidia did not inform me in which
driver release they had appied the fix for the problem I reported. But at
least they informed me that they had fixed the driver and had sent it for
fi
Hi Adrian,
These errors are weird. And it looks like GLSL compiler does not know what is
gl_LightSource size ? I am puzzled because ite GLSL built in variable.
I looked for web for this error. I have found a thread on gamedev.net.
http://www.gamedev.net/community/forums/topic.asp?topic_id=3816
Hi Guys,
Similar problem also existed on older NVidia drivers in Windows XP.
Framerate was slowly degrading when stats were on.I wrote about this few
months ago. Recent driver realeases do not cause this effect. Try latest
178.24 drivers if NVidia and Windows is you configuration.
Cheers,
Wo
David,
All classes belonging to ViewDependentShadow group derive shaders from
StandardShadowMap. If you look at these shaders you will notice that they are
split into main vertex and fragment shader and shadow vertex and fragment
shader. Main shaders do nothing extraordinary they simply emulate
David,
> I saw this. Maybe I'm being daft, but presumably this only helps when you
> have the SAME shader for the entire shadowed scene? I have a situation where
> > the shadowed objects have a variety of different shaders. If I'm missing
> something obvious, my apologies.
Thats true. But oppo
Hi David,
Btw. Shadow shaders are extremaly simple. Vertex shader simply performs texgen
operation on stage 1 to produce shadow tex coords. Fragment shader simply
performs texture from shadow map. So generally you may even hardcode these
operation into your main shaders.
In my company we use
Rick,
I don't know how to help you with your particular problem. But I hope these
2 hints could be useful:
I suppose it would be fairly simple to make similar adjustment for LisPSM as
you did for ShadowMap. Texgen matrix for LispSM is set in
MinimalDrawBoundShadowMap line 225. For safety you shou
Hi Again Rick,
Small errata: I forgot to add .cpp suffixes to the files I suggest to
modify. So fixes should be done in
MinimalDrawBoundShadowMap.cpp line 225
and
StandardShadowMap.cpp line 753
Let us know if this helps, if it does, I will be smarter next time when this
question appears again.
Hi Rick,
I am afraid you are on your own - I will not be able to help much. Shadow
mapping issues could be really hard ;-( I would need to grab similar board,
roll up the sleeves and start debuging. But I don't have the time nor access
to such hardware.
> [..]
> When I just use StandardShadowMa
Hi, I wish I had some friends at NVidia. But unfortunately they not seem to
treat me specially. I went through standard Bug report form on developer
NVidia website. At least last time they let me know they repeated the bug
and did something about it. 2 former cases when I sent reports were ignored.
Hi Marco,
Its really weird. I am pretty much sure we have tested this with Vista x64,
but maybe not the latest drivers. May I send you simpified OpenGL only repro
I have sent to NVidia as a bug report ? I am curious if the crash will
happen with it as well ?
Cheers,
Wojtek
-Original Message
Thanks, Marco.
I will send this code tomorrow from my office. I don't have it at home.
Cheers,
Wojtek
Hi Wojtek,
> Its really weird. I am pretty much sure we have tested this with Vista
> x64,
> but maybe not the latest drivers. May I send you simpified OpenGL only
> repro
> I have sent to
ue should never
crash applications.
Marco
----------
From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
Sent: Wednesday, November 12, 2008 11:42 AM
To:
Subject: Re: [osg-users] crash
with"multimonitormultithreadnVIDIAworkaround" enab
Hi Robert,
Could you one of your guys implement that original workaround as a
runtime optional flag in GraphicsWindowWin32, with an env var settings
it's default value. I'd suggest that this workaround is now to set
off.
I will see what I can do.
Wojtek, do you know what driver version numb
Hi, Guys
Unfortunately we don't always want or can use precompiled headers. Besides,
argument about precompiled headers is double sided sword. Such precompiled
headers could be also used to enable these warnings after all osg headers with
disabled warnings were included. In my humble opinion th
more wordy and while of dubious practical
value would at least fix the warnings.
Robert.
On Fri, Nov 21, 2008 at 2:13 PM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
Hi, Guys
Unfortunately we don't always want or can use precompiled headers.
Besides,
argument about precompiled h
Hi Robert,
I have restored MSVC disabled warnings in osg/Export. Difference is they are
now disabled only when OSG_DISABLE_MSVC_WARNINGS macro is defined. This
macro is set through CMake options and autogenerated in osg/Config. Simon
suggested that it would be cool if we had more control over
Hi Guys,
I generally agree that suppressing these warnings is bad. Truth is if they
were not disabled at the early days of OSG most of them would be not present
today because authors would fix them in other way. And this poses a danger
for the future. As along as we keep them disabled authors
Hi Kim,
Im curious which OSG version you use ? Could this be that you have dual view
setup ? Maybe you have the same error Marco Jez reported recently. You may try
to change OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND and see if it
helps.
Cheers,
Wojtek
- Original Message -
Hi Richard,
If you don't mind using vertex shader then look at shaders defined in
osgShadow::StandardShadowMap.
But I understood that you actually don't want to use vertex shader and you
keep fixed vertex pipeline (which is reasonble in many cases). Assuming that
we have one light only (all
Hi Paul,
Can anybody tell me why I have this osgShadow compile problem using OSG
2.7.8 when compiled using GCC 3.2.3? I think I had the same problem when I
attempted to compile 2.7.7 as well..
I am not sure what is recommended solution for your case. Issue is probably
related to usage of hea
Roger,
I am following your posts but unfortunately cannot find any strong suggestion
to help. But I may offer two blind shots, maybe they bring some relief to your
problem.
1: I have found that we accidentally created two independent classes with
DrawableDrawWithDepthShadowComparisonOffCallbac
Guys,
Sorry if I offend anyone but I thought this should be obvious. Looks like only
J-S got it ;-) So I now shout to make it clear:
If you don't like Vertex shader I use you can easily turn it off and switch to
Fragment shader only version. You can easily adopt approach where you have only
o
Subject: Re: [osg-users] Bug : LightSpacePerspectiveShadowMapDB and cow.ive
Wojciech Lewandowski wrote:
Guys,
Sorry if I offend anyone but I thought this should be obvious. Looks like
only J-S got it ;-) So I now shout to make it clear:
If you don't like Vertex shader I us
osg::Vec3 projectedPoint = osg::Vec3( x,y,z ) * camera->getViewMatrix() *
camera->getProjectionMatrix();
bool pointInFrustum = osg::BoundingBox( -1, -1, -1, 1,1,1 ).contains(
projectedPoint );
Cheers,
Wojtek Lewandowski
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Both
methods are good you. Use the one which is more convenient ;-)
Regards,
Wojtek
- Original Message -
From: "Robert Balfour" <[EMAIL PROTECTED]>
To:
Sent: Sunday, December 30, 2007 10:10 PM
Subject: Re: [osg-users] Is point in view?
> Wojciech Lewandowsk
I have not done it myself so I am not 100 % sure but from what I've heard CMAKE
simply does not find your VS 2008 installation on standard predefined paths.
Workaround is to run cmake from VS 2008 command prompt. This is what I've
heard. If this does not help ask again in new year. My collegues
>Just because the issue was encountered on Vista doesn't mean it's
>related to Vista. In this case, trying to run CMake 2.4.x with Visual
>Studio 2008 even on XP would have given the same issue, because CMake
>2.4 doesn't recognize VS 2008. You need CMake 2.5. Even on XP.
I 100% agree. Its non OS
Hi,
I am also very surprised to see that use of index arrays/buffer objects
impacts performance. Is this a limitation of OSG or OpenGL ? I always
thought that Hardware Vertex Buffer + Hardware Index Buffer should be the
best performing scenario.
I just checked GPU_Programming_Guide on NVidia
ot;OpenSceneGraph Users"
Sent: Monday, January 07, 2008 12:20 PM
Subject: Re: [osg-users] VBO
> On Jan 7, 2008 10:58 AM, Wojciech Lewandowski <[EMAIL PROTECTED]>
> wrote:
>> I am also very surprised to see that use of index arrays/buffer objects
>> impacts pe
Hi, Philip,
FYI: All integral types in Win64 are the same size as they were in Win32.
Only ptr types got "promoted" to 64 bit. See this article:
http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx
Cheers,
Wojtek Lewandowski
- Original Message -
From: "Philip Taylor" <[EMA
Hi,
I asked similar question some time ago. In the meantime I figured it out
myself. You don't need to add light to shadowed scene nor it does not need
to be present in fixed location in viewer scene hierarchy. I assume of
course that you have at lest one light somewhere in hierarchy. In case o
Hi,
>>o OVERRIDE is effectively an instruction to ignore an
>> attempts of StateSet below it to set RenderBin's.
>
> Understood. Can you give me an example of why someone would want to do
> this?
Pardon me, to step into this discussion but I think I have a situation where
renderBin override
Hi again,
Sorry I was in hurry and I made many errors in my last post it was almost
unreadable. I repeat it with at least few of them fixed ;-)
You won't find osgShadow::ShadowMap::init it on a Stack Trace. You have to
place breakpoint into it. You do this to make sure its actually NOT CALLED
Hi,
You would need to put breakpoint into osgShadow::ShadowMap::init. When it
crashes its probably due to not calling init. So you won't find it on Stack
trace. If crash happens you its probably some function under
ShadowMap::cull. getDataVariance is called with _stateset being NULL ?
Did yo
Hi,
I believe that receivesShadowTraversalMask is used somewhere in
ShadowedScene code to initialize NodeMask for traversals. Its common code
for all techniques. Check ShadowedScene or ShadowedTechnique. Its must be
there.
Cheers,
Wojtek
-Original Message-
From: [EMAIL PROTECTED]
[mailto
For tests, you may derive your ShadowMap from osgShadow::ShadowMap, override
init and cull methods. In this way you will be able to check if init was
called. Of course I have not tested it but the code should look more or less
like this:
#include
class MyShadowMap: public osgShadow::ShadowMap {
I haven't suggested that it won't work with osgProducer. I said that your
poroblem ie ShadowMap init not being called by Update Traversal may be
caused by some differences beetween osgViewer and osgProducer viewers. I
would not go that far to say that osgProducer is to blame. But osgShadow
example
Hi,
We have one 64bit setup in our company. It was not used for few months, but
in the summer we we built couple osg releases using it. In that time, it was
just a matter of selecting target 64 bit VS environment, when Cmake was run
for the very first time in OSG directory. This selection is also
Hi Robert,
I am struggling with building decent ShadowMapping approach for flight sim
application. Due to performance requirements I am hesistant to use multipass
PSSM and I am trying to implement (one extra pass only) some kind of
perspective shadow mapping derived algorithm. I went through Trape
, or just some bugs lurking
that I have found.
As I'm so short on time I can't really dive any deeper than this, good luck,
Robert.
On Jan 26, 2008 12:37 PM, Wojciech Lewandowski <[EMAIL PROTECTED]>
wrote:
> Hi Robert,
>
> I am struggling with building decent ShadowMappi
Hi everyone,
Does VPB (or OSGDEM) allow to make holes in the terrain mesh for high fidelity
vector models ?
If not, maybe you can offer some suggestions how to do it ?
Thanks in advance,
Wojtek Lewandowski
___
osg-users mailing list
osg-users@lis
de example so I thought that maybe something like this was already
done.
Cheers,
Wojtek Lewandowski
> Wojciech Lewandowski a écrit :
>> Hi everyone,
>>
>> Does VPB (or OSGDEM) allow to make holes in the terrain mesh for high
>> fidelity vector models ?
>> If not,
/OSGDEM
terrain.Possible ?
Have you looked at osgTDS
http://www.andesengineering.com/Projects/TDS/
Brian
On Feb 8, 2008 6:16 AM, Wojciech Lewandowski <[EMAIL PROTECTED]>
wrote:
Hi everyone,
Does VPB (or OSGDEM) allow to make holes in the terrain mesh for high
fidelity
I implemented Trapezoidal and LiSpPSM. Actually most of the time was spent
on algorithms finding minimal shadowed scene bounds under OSG. It was a key
to good shadow mapping results. I will try to contribute LispSM when I am
done with all the issues.
Cheers,
Wojtek
-Original Message-
Fro
Hi,
ShadowMap::cull invokes culls traversal for both main camera
(ShadowReceiving) graph & shadow camera (ShadowCasting) graphs. So if you
block whole cull on ShadowMap level - it won't draw the scene as well. The
trick is to block only the portion that culls ShadowCasting graph.
See the osgS
I have spent couple months banging my head against the wall, implementing
perspective shadow mapping algortihms and that is the only rason I know how
osgShadow::ShadowMap works ;-).
Wojtek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Jean-Sebastien Guay
S
Hi
will this implementation be avaible for the osg community, new shadow
implementation ?
2008/2/11, Wojciech Lewandowski <[EMAIL PROTECTED]>:
I implemented Trapezoidal and LiSpPSM. Actually most of the time was spent
on algorithms finding minimal shadowed scene bounds under OSG. It was a
Hi,
I developed two methods to compute convex hull of visible scene portion:
A: one based on cull stage
I scan render leaves generated by main camera cull traversal and compute
minimal convex hull around them
B: second based on draw stage
I prerender the scene to small resolution depth
Hi J-S,
>This is the part I'm having trouble with. I actually don't mind using
>the scene bound I get with the ComputeBoundingBoxVisitor, but getting a
>usable camera frustum (both for main and light cameras) and then
>intersecting those is the hard part for me. Any tips there? How do you
>create
Hi J-S,
> Thank you Wojtek, I'll check that out! I'm really very grateful to you
> for contributing this. I've been banging my head on this and we're still
> on OSG 2.2 here so I didn't think of going to see in the new additions
> if there was something that would help me out.
You're welcome.
Hi Robert,
We noticed another issue. When statistics bars are on - framerate slowly
degrades. This happens with osgviewer dumptruck.osg for example. When stats
are on draw time slowly grows and framerate starts to decrease.
Tested with latest svn (2.3.4), windows xp & vista, OSG built with VS 2
: OpenSceneGraph Users
Sent: Friday, February 15, 2008 1:10 PM
Subject: Re: [osg-users] Framerate vs stats?
On Fri, Feb 15, 2008 at 12:57 PM, Wojciech Lewandowski <[EMAIL PROTECTED]>
wrote:
Hi Robert,
We noticed another issue. When statistics bars are on - framerate slowly
degrades
- Original Message -
From: Wojciech Lewandowski
To: OpenSceneGraph Users
Sent: Friday, February 15, 2008 2:42 PM
Subject: Re: [osg-users] Framerate vs stats?
Thanks Serge,
I have to withdraw my claim. Your mail gave me something to think and I
checked whether problem exists in
Hi J-S,
> I've seen that, but only when compiled in debug mode... Check to see if
> you're in debug. Never do performance timing in debug mode :-)
>
> If you're in release, then I haven't seen this, might be a driver bug...
Its in Release mode. But we also found problem is present only in
multi-
u.
>>
>> Cheers,
>> Wojtek
>>
>>
>>
>>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] Behalf Of Brian
>> Sent: Friday, February 08, 2008 6:28 PM
>> To: OpenSceneGraph Users
>> Subject
Hello everyone,
I have following problem: Shadow Mapping - so called duelling frusta case ie
light direction opposite to view direction. Objects drawn into Shadow Map also
contain LOD nodes. When rendering shadow map LODs are drawn based on distance
computed from shadow camera. But this is plai
Hi J-S,
I am not sure what is the difference between EyePoint and ViewPoint but
really hope that EyePoint/ViewPoint duo was introduced for problems like
mine. If I only knew how to use them to my advantage ;-)
Cheers,
Wojtek
- Original Message -
From: "Jean-Sébastien Guay" <[EMAIL
Hi Paul,
> Ideally, you would want the shadow caster's LOD to be selected based on
> the
> distance between the eyepoint and the shadow receiver, wouldn't you?
Actually I would like it to be based on the distance from eyepoint to Shadow
Caster (measured in main camera view space). If its based
Hi Paul,
> If your eye is close to the shadow but far from the caster, then the
> shadow
> covers a large pixel area and the caster covers a small pixel area. This
> is
> exactly the case where you would want to use two different levels of
> detail
> for the caster -- one to create a high resol
Hi Brian,
> It looks like you'll need to create a custom cull visitor that stores the
> desired eye point and overrides the CullVisitor::getViewPoint method to
> return the stored eye point instead of the CullStack view point.
Thats sounds like it something I might be able to do ;-). Do you know
Welsh - mogumbo 'at' gmail.com
www.reallyslick.com | www.mogumbo.com
> Message: 5
> Date: Tue, 26 Feb 2008 15:18:13 +0100
> From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
> Subject: [osg-users] Problem to consider: Shadow maps and LOD
> comput
retty safe.
>
> Caveat - I've only looked at the code and haven't tried this.
>
>
> Brian
>
> [EMAIL PROTECTED] wrote: -
>
>
> To: "OpenSceneGraph Users"
> From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
> Sent by
will send proper submission.
Cheers,
Wojtek
- Original Message -
From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users"
Sent: Tuesday, February 26, 2008 9:28 PM
Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD
computation
Hi Justin,
Look at void osgUtil::RenderStage::draw(osg::RenderInfo&
renderInfo,RenderLeaf*& previous) method.(Line 825 in currnt SVN
src/osgUtil/RenderStage.cpp). Its all there.
1: Prerender cameras add Prerender stages. Prerender stages are drawn first.
Line 833:
drawPreRende
Of Wojciech
Lewandowski
Sent: Thursday, February 28, 2008 9:07 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ...
whowins?
Hi Justin,
Look at void osgUtil::RenderStage::draw(osg::RenderInfo&
renderInfo,RenderLeaf*& previous) method.(Lin
Hi Robert,
> I'll be doing some merges this morning and once this done will spend a
> bit of time reflecting on this issue.
Thank You, I don't opt for any specific solution. Anything what gives a
method to grab current State object will help. I gues Justin will say the
same if he would able to
Sounds like default Light Model ambient Look at OpenGL docs for
glLightModel & GL_LIGHT_MODEL_AMBIENT.
Cheers,
Wojtek
- Original Message -
From: "Necdet Can Atesman" <[EMAIL PROTECTED]>
To:
Sent: Friday, February 29, 2008 1:10 AM
Subject: [osg-users] Complete darkness
> Hi folks,
Thanks, Robert. I think I will be also happy with this solution ;-). I will
be leaving for two weeks soon so will not have the chance to test now it but
I will do this when I am back.
I noticed a typo in const getter function for InitialCallback. Method is
named getUnitialDrawCallback.
Cheers,
Wo
h 01, 2008 1:01 PM
To: [EMAIL PROTECTED]; OpenSceneGraph Users
Subject: Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ...
whowins?
On Fri, Feb 29, 2008 at 9:18 PM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> I noticed a typo in const getter function for InitialCallba
: Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ...
whowins?
On Sat, Mar 1, 2008 at 12:31 PM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> I just have sent a fix for heavier issue. New
> Camera:DrawCalback::operator()( RenderInfo & ) needs to be exported in
> Windows. O
Hi Robert and All,
I am back from vacations. Ready to take the responsibility for my changes in
osgShadow::ShadowMap ;-). Does the problem Adrian refers happen only with
PSSM or standard ShadowMap as well ? Its not obvious from forum emails and I
am unable to replicate it with standard ShadowMa
results across and models
sizes.
Robert.
On Mon, Mar 17, 2008 at 9:47 AM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> Hi Robert and All,
>
> I am back from vacations. Ready to take the responsibility for my changes
> in
> osgShadow::ShadowMap ;-). Does the problem Adr
Robert,
I replicated the problem with osgShadow::ShadowMap. I will try to find the
cause...
Cheers,
Wojtek
- Original Message -
From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users"
Sent: Monday, March 17, 2008 11:57 AM
Subject: Re: [os
rotect it from inheritance overriding ? If yes then we got a lot of
code to review and adjust ...;-(
Cheers,
Wojtek
- Original Message -
From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users"
Sent: Monday, March 17, 2008 12:29 PM
Subjec
ither changing the defaults in
CullSettings so that less of the inherited state comes down into the
local Camera, or we override the defaults locally. I'd suggest we
change the defaults locally and review the defaults in light of how
many changes we make.
Robert.
On Tue, Mar 18, 2008 at 9:18
Hi Robert,
>> In other words from now when we want a fixed projection matrix we need
>> to
>> make two calls:
>>
>> camera->setComputeNearFarMode( osg::Camera::DO_NOT_COMPUTE_NEAR_FAR );
>>
>> camera->setInheritanceMask( camera->getInheritanceMask() &
>> ~osg::Camera::COMPUTE_NEAR_FAR_MODE );
Hi J-S,
I was on vactions. But if you are still interested I did the test you
wanted. I have added ThreadingHandler to shadow example. Pressing m does not
crash the program but freezes shadow map. Shadow map is no longer refreshed.
I did the same quick test with prerender example and results are s
201 - 300 of 597 matches
Mail list logo
