Hi,
What is the desired way to enable shadow rendering?
By using the ShadowEngines (Simple, Trapezoidal, ..) like in shadows example?
Browsing the code I found things like ShadowStage and several handlers e.g. for PCF? How are those to be used?
Using the engines, is it possible to define nodes that do not cast and/or receive shadows?
Thanks in advance,
Michael
Gesendet: Donnerstag, 30. Mai 2013 um 11:29 Uhr
Von: "Michael Raab" <michael-r...@gmx.de>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] Porting 1.8 to 2.0
Von: "Michael Raab" <michael-r...@gmx.de>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] Porting 1.8 to 2.0
Hello Carsten,
thanks for your answers! I have more questions :-)
> [1] In hindsight I'd rather not have introduced TransitPtr, but it did
> seem like a good idea (to me) at the time :-/
> I have experimented a bit with a branch that mostly removes use of
> TransitPtr, but it is an application breaking change, so I'm not sure I
> want to pursue it.
> seem like a good idea (to me) at the time :-/
> I have experimented a bit with a branch that mostly removes use of
> TransitPtr, but it is an application breaking change, so I'm not sure I
> want to pursue it.
Maybe you can start a debate on the mailing list! I think most users will read here from time to time
and have an opinion on this..
1.)
We have the need to update some shader variables frequently, e.g. those who depend on our system time.
With 1.8 I checked each frame for newly created SHLChunks und there checked for certain uniform variable names using method hasUniformVariables().
Once found I updated the variables each frame..
How can this done in 2.0, may be there is a smarter way...
What I recently saw were OSGProceduralVariables. Can they be used for this purpose? Can all my shader programs share one variable, e.g. for current system time?
What happens if I write an OSGProceduralVariable to osb und reload it?
2.) Definitions: What is
- a stage?
- a partition?
- draw mode: SequentialPartitionDraw vs. ParallelPartitionDraw?
- a view area?
3.) commitchanges()
Could you please explain shortly what this exactly does? Is this relevant for multi-threaded/cluster applications only?
Thanks in advance,
Michael
Gesendet: Donnerstag, 30. Mai 2013 um 01:18 Uhr
Von: "Carsten Neumann" <carsten_neum...@gmx.net>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] Porting 1.8 to 2.0
Von: "Carsten Neumann" <carsten_neum...@gmx.net>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] Porting 1.8 to 2.0
Hello Michael,
On 05/24/2013 04:28 AM, Michael Raab wrote:
> At a first look it works; I will test in details the next days. Thanks!
> I have more questions:
> 1.) RenderAction::setSmallFeatureCulling()/::setSmallFeaturePixels() -
> was this also removed?
yes.
> 2.) The compiler complains about converting TransitPointers to plain
> pointers, e.g. when a newly created object is given to a method:
> Example:
> viewport->setBackground(osg::DepthClearBackground::create()); // does
> not compile
> needs to be converted to:
> osg::DepthClearBackgroundPtr dcb = osg::DepthClearBackground::create();
> viewport->setBackground(dcb);
> We have much code that will need to be rewritten this way. Why can a
> RecPtr converted but a TransitPtr not?
one purpose of TransitPtr is/was to avoid code like this:
OSG::Viewport* vp = OSG::Viewport::create();
which produces a dangling pointer (the other is a micro-optimization to
avoid an increment, decrement on the ref count) [1]. Allowing TransitPtr
to implicitly convert to a raw pointer therefore defeats most of it's
purpose.
Cheers,
Carsten
[1] In hindsight I'd rather not have introduced TransitPtr, but it did
seem like a good idea (to me) at the time :-/
I have experimented a bit with a branch that mostly removes use of
TransitPtr, but it is an application breaking change, so I'm not sure I
want to pursue it.
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
On 05/24/2013 04:28 AM, Michael Raab wrote:
> At a first look it works; I will test in details the next days. Thanks!
> I have more questions:
> 1.) RenderAction::setSmallFeatureCulling()/::setSmallFeaturePixels() -
> was this also removed?
yes.
> 2.) The compiler complains about converting TransitPointers to plain
> pointers, e.g. when a newly created object is given to a method:
> Example:
> viewport->setBackground(osg::DepthClearBackground::create()); // does
> not compile
> needs to be converted to:
> osg::DepthClearBackgroundPtr dcb = osg::DepthClearBackground::create();
> viewport->setBackground(dcb);
> We have much code that will need to be rewritten this way. Why can a
> RecPtr converted but a TransitPtr not?
one purpose of TransitPtr is/was to avoid code like this:
OSG::Viewport* vp = OSG::Viewport::create();
which produces a dangling pointer (the other is a micro-optimization to
avoid an increment, decrement on the ref count) [1]. Allowing TransitPtr
to implicitly convert to a raw pointer therefore defeats most of it's
purpose.
Cheers,
Carsten
[1] In hindsight I'd rather not have introduced TransitPtr, but it did
seem like a good idea (to me) at the time :-/
I have experimented a bit with a branch that mostly removes use of
TransitPtr, but it is an application breaking change, so I'm not sure I
want to pursue it.
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
