Hi James,
Its not direct answer to your questions but a code snippet overloading
Program which I used to change shader variant depending on compilation/link
result (from most advanced to more basic fallbacks). This approach was
quite simple I tested Program compilation result including compilatio
Hi James,
Its not direct answer to your questions but a code snippet overloading
Program which I used to change shader variant depending on compilation/link
result (from most advanced to more basic fallbacks). This approach was
quite simple I tested Program compilation result (including
compilati
Hi Chris,
This is the idea I wanted to try myself some day but the day for this never
came. I probably would attempt the method described here
https://stackoverflow.com/questions/25058627/is-it-possible-to-render-an-object-from-multiple-views-in-a-single-pass
(see
answer with 4 likes).
Cheers,
Wo
Hi Alberto,
You may need to add support for clip planes via gl_ClipVertex or
gl_ClipDistance to your shaders (which one depends on GLSL version used
-see
https://stackoverflow.com/questions/19125628/how-does-gl-clipvertex-work-relative-to-gl-clipdistance).
My experience with these vars was not alw
Hi Ravi,
We usually do not make such extensive checks but we were debuging other
interesting VBO problem so we also checked yours. Few observations.:
0. I noticed you used multithreaded configuration and switched to
SingleThreaded. Multithreaded config creates 2 instances of GL resources
and I th
ł(a):
> Hi Wojtek,
>
> On Mon, 30 Jul 2018 at 08:53, Wojciech Lewandowski
> wrote:
> > I understand my setDrawBuffer / setReadBuffer observation was probably
> not the only problem. But I believe this one is genuine problem that should
> not be neglected. So I decide t
Hi Stuart,
I understand my setDrawBuffer / setReadBuffer observation was probably not
the only problem. But I believe this one is genuine problem that should not
be neglected. So I decide to write this small followup and elaborate a bit
to make it clearer. In the meantime I did some more research
Hi,
I have just investigated the issue with OSG view set in QT window and
osgEarth REX engine which resulted in completely black screen. This was
probably different problem, but it sounds bit like yours so I decided I
will share my observations. Maybe it will help someone. What I found to be
an is
Hi, Igor,
I got interested in this problem and checked your code by converting it to
pure osgViewer. Here are my observations:
I believe you do have circular reference. Your class Scene is a callback.
So RootNode points to callback but Scene callback points to RootNode. Hence
circular ref.
Howev
Hi,
Was going to propose what Glenn already proposed. This should work with
uniform scales on x,y,z coord. And IMHO that formula is more precise when
dealing with normals than vertices. Thats because the precision issues are
somewhat related to huge earth translation offsets in ModelView matrix.
N
Hi,
AFAIK there is also a https://developer.nvidia.com/nvapi library.
Unfortunately I have no personal experience with this but I believe it can
be used to prgramatically override the setings usually set with NVidia
Control Panel.
Cheers,
Wojtek
2018-05-10 20:18 GMT+02:00 Daniel Emminizer, Code
PS: the multiplication is in reverse order
Ah, indeed, sorry multiplication order should be reversed. I wrote that
from top of my mind. Even though I use OSG every day I sometimes make some
silly mistakes too.
Regards,
WL
2018-03-19 16:42 GMT+01:00 Antoine Rennuit :
> @Julien,
>
> You are righ
Hi,
Knowing the 3D coordinates of a point, is there an easy way in OSG to
> compute its 2D projected equivalent (i.e. in pixel coordinates)?
Yes. In general your pixel coord is computed as:
pixel_coords = WindowMatrix * ProjectionMatrix * ViewMatrix * ModelMatrix *
point;
Your solution may var
some other callbacks attached) and instead just added it in dummy
group.
Cheers,
Wojtek Lewandowsk
2017-12-23 10:43 GMT+01:00 James Turner :
>
>
> On 23 Dec 2017, at 09:28, Wojciech Lewandowski
> wrote:
>
> Unfortunately I could not dig out the code I had to solve this problem.
Hi, James,
Unfortunately I could not dig out the code I had to solve this problem. But
I did fight with it on couple occasions. I do remember that often the
solution I adopted had to use 2 callbacks (cull/update callback +
prerender/render/or postrender callbace). One update/cull callback was
need
Hi Jiechang,
I am not sure I am able to pinpoint your problem. I see some weak spots but
I am not sure if those are the true causes of your problem. And don't want
to give wrong clues. Can you write short repro program which demos your
problem ? I may then fix it and send you back.
To learn you m
Hi Jiechang,
Few observations:
1. You write you want rotation around Y axis (0,1,0). But you rotate around
Z axis (0,0,1). Btw there are osg::X_AXIS = (1,0,0) , osg::Y_AXIS =
(0,1,0), osg::Z_AXIS = (0,0,1) constants defined in OSG which you may
directly.
2. What is the origin variable in your exa
Hi Bruce,
Just from top of my head.
1. Check and verify if all osgXXX.dll and OpenThreads.dll are loaded from
correct installation directories. Similar errors often occur if
Debug/Release/Rev libs get mixed. VS Output pane displays all loaded DLLs
with long paths so its easy to verify if some lib
Hi Jan,
... with more slave cameras it simply do not work ...
Bugs happen (so I am not going to exclude them). But in my experience its
very easy to burn whole GPU memory with too many FBOs. For example: 4k x
4k, 4 sample RGBA (4bytes) + DEPTH(4bytes) FBO takes 512 MBs. With double
buffered
Well...If you don't need too big resolution, you may try to simply
oversample. Set PBUFFER at 2x or 4x of your desired res. Render and then
downsample to your image res. Multisampling does not differ much from it
(it just more effective with lower number of samples and its randomized
sample positio
Hi Krzysztof,
Not sure about PBO but FBO support in OSG works with multisampling.
See
Camera::attach(
BufferComponent buffer,
osg::Texture* texture,
unsigned int level,
unsigned int face,
bool mipMapGeneration,
unsigned int multisampleSamples,
unsigned int multisampleColorSamples)
Hi Werner,
I think you may try using osg::Registry::instance()->addReaderWriter(
YourReaderWriterInstance ) to add your own localy defined RW. Your RW will
need to override supportedExtensions() and/or acceptsExtension() virtual
methods. But I guess you must have already done that
Cheers,
Woj
+02:00 Wojciech Lewandowski :
> Could you modify one to OSG examples to illustrate the problem so
>> others can reproduce it. I have paged databases to test against, but
>> not the particular FBO usage that you are using along with it.
>
>
> Ok. I'll try to make a rep
ield :
> On 9 October 2016 at 11:27, Wojciech Lewandowski
> wrote:
> > Hi, Robert. Thanks for quick response.
> >
> >> Perhaps a flag in osg::Texture might be appropriate to declare whether
> >> this Texture is
> >> suitable for reuse or not.
> >
&
ool scheme needs an
> ability to not place texture's assigned with FBO's into the pool, or
> at least mark them as unsuitable for reuse. Perhaps a flag in
> osg::Texture might be appropriate to declare whether this Texture is
> suitable for reuse or not.
>
> Robert.
>
Hi, Robert,
I believe we encountered an issue (bug?) related to maxTexturePoolSize
handling. Our application is osgEarth + few high res overlays. We set
OSG_TEXTURE_POOL_SIZE = 350 MB. It was recommended to us as one of env vars
to let osgEarth perform optimally. Overlays are rendered as RTT camer
Welcome :-)
Wojtek
2016-10-06 3:46 GMT+02:00 liu ming <81792...@qq.com>:
> hi Wojtek,Thank you very much,you perfect solved my problem.According to
> your code,Texture2D worked,maybe it is something wrong about Texture1D.
> Thank you.
>
> --
> Read this topic online here:
> http:/
Hi guys,
Here is the repro code. In cmake project.
Change use_data1D value in test.cpp to see the problem.
One note: I tested it with GL 3 Osg build. There may be issues I omitted if
you run it with GL1/GL2/GL3 compatibility OSG build.
Cheers,
Wojtek
2016-10-05 14:38 GMT+02:00 Wojciech
Hi Liu,
You got me interested and I created a repro of your problem. I will send it
in followup mail (to be sure this message passes in case zip attachments
were prohibited and message got blocked).
I think you see a genuine issue.
I have found that texture1D seems to be a problem. When I used t
Hi,
I think internal format GL_RGBA16 normalizes your float values to 0..1
range. Try GL_RGBA16F_ARB instead.
Cheers,
Wojtek Lewandowski
2016-10-04 17:00 GMT+02:00 liu ming <81792...@qq.com>:
> Hi,
>
> I want to send a set of data to geometry shader with osg::texture,I've
> got a problem:in t
Hi,
Not sure if this helps but I believe you may define own Ellipsoid with
EllipsoidModel. Just define it with both Radii the same and voila you have
the sphere ...
Cheers,
Wojtek Lewandowski
2016-09-26 23:54 GMT+02:00 Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de>:
> Hi Inna,
>
> It
Hi Paul,
I guess you have one channel float data. Certainly this is wrong:
rImage->setImage(
rawImage.rows(),rawImage.cols(),arrayDepth,
GL_LUMINANCE, GL_RGB32F_ARB, GL_FLOAT,
pData, osg::Image::NO_DELETE );
At least GL_RGB32F_ARB should be swapped with GL_LUMINANCE. First you pass
internal form
Trajce,
I wrote that code but its old enough to not remember details. But from what
I remember original LispSM paper provided some formula to compute
Perspecive Matrix which I implemented and their sample code used different
formula and also have found later version of code which used another
form
Thanks, Looks good to me.
Wojtek
2015-04-27 21:22 GMT+02:00 Robert Osfield :
> Hi Wojtek,
>
> I have decided I'd rather change the method name and break the build
> rather than silently change the behaviour of method in a way that
> could break end user code. What I have gone for is:
>
> --- inc
Hi Wojtek,
>
> On 27 April 2015 at 12:15, Wojciech Lewandowski
> wrote:
> > I believe both can be correct but it looks like in Box case r1 is ratio
> of
> > segment length measured from start and r2 measured backwards from the
> > segment end. For Sphere both r1 and r
; Robert.
>
> On 25 April 2015 at 13:11, Wojciech Lewandowski
> wrote:
> > Hi, Robert,
> >
> > I have just stumbled on small issue in my intersection code which turned
> out
> > to be related to different interpretation of r2 param returned by
> > LineSegment
Hi, Robert,
I have just stumbled on small issue in my intersection code which turned
out to be related to different interpretation of r2 param returned by
LineSegment::intersect( BoundingBox, r1, r2 ) and LineSegment::intersect(
BoundingSphere, r1, r2 ).
Example Code:
osg::BoundingBox box( -1,-1
Hi, Robert,
I am not actively working with any code which would require shader
composition at the moment but I saw few such efforts in various projects in
the past, so I am really glad OSG is going to implement own scheme and
users will not need to invent the wheel anymore ;-). As someone only mil
Hi Trajce,
I spent good time to go through the archive looking for the announcement
> from Robert from time ago about the changes in osg::Geometry with no luck.
> And I don't mean the last one that now it is a regular osg::Node, but was
> something else, and I don't remember what was it.
I beli
with original code.
Cheers,
Wojciech Lewandowski
2014-08-06 0:44 GMT+02:00 Trajce Nikolov NICK :
> Hi Community,
>
> My client have a setup with image distortion over a dome, multiple
> channels, and along with the projectors there is an API coming that is well
> integrated in OS
Mickael,
As far as I know none of existing techniques in OSG does what you want. You
will need to roll up your sleeves and work hard to obtain the effect you
wish.
I was once contracted to do multiple shadow lights with full spherical
coverage of light field. Its proprietary code and I cannot sha
the default with the osg::Texture
> subclasses.
>
> Thoughts?
> Robert.
>
>
> On 24 January 2014 00:29, Wojciech Lewandowski
> wrote:
>
>> Hi Frank,
>>
>> I believe that GL_TEXTURE_2D_MULTISAMPLE should not applied as mode. Its
>> the same situation as
Hi Frank,
I believe that GL_TEXTURE_2D_MULTISAMPLE should not applied as mode. Its
the same situation as with GL_TEXTURE_2D_ARRAY. These texture types are
only availalble to programmable pipeline. Setup of Texture modes are
neccessary for fixed pipeline. GL_TEXTURE_2D_ARRAY should be set only vi
I think this anwers your question:
http://www.gamedev.net/topic/544990-gl_max_texture_units-is-wrong/
Cheers,
WL
2013/12/16 Daniel Schmid
> Interesting. So could this be a bug in osg?
>
> Did you try to query GL_MAX_TEXTURE_UNITS and check if it says 4 ? I
> wonder if this value does not only
Hi Daniel,
I confirm your observation. I, however, do not agree that its a TexGen
problem. Frankly I do not know what it is, and I had no time to
investigate, but I think its maybe relate to TexEnv settings. I only made a
following test: I zeroed a spotlight texture (memset( image->data(), 0,
imag
Hi Daniel,
I doubt your test methodology is correct. For recent years I've beeen often
using TexGen on stage 6 and 7. On many GeForces and some Radeons and even
Intel HD 3000. I think TexGen used at 0-7 is very common and thus your
observation must be wrong...
Perhaps you read the Microsoft defaul
Hi Sebastian,
Just an extra thought that came to me. Terrain LOD paging may cause the
elevation jumps too. When LODs change meshes get denser or less dense - new
vertices show up or excess vertices hide and that may also bring lot of
surprises.
Cheers,
Wojtek
2013/12/5 Wojciech Lewandowski
Hi Sebastian,
Perhaps your GPU can use doubles ? Many of them can these days. You may
also try to refactor the code to use pairs of floats (as base and offset)
which in theory may be almost as precise as double. It may be however very
tricky for such non-linear math as geographic projections...
C
Hi Raymond,
Just a thought. Most probably wrong. I saw similar errors with TortoiseGIT.
But I supposed similar problems could be triggered by other programs in the
background scanning filesystem for changes. In my case killing TortoiseGIT
cache process was helping me.
Wojtek
2013/11/22 Raymond
c4(0.);
>for ( int i=0; i depth += texelFetch( depthTex, itc, i ).x;
> color += texelFetch( colorTex, itc, i );
>}
>gl_FragDepth = depth * NUM_SAMPLES_INV;
>gl_FragColor = color * NUM_SAMPLES_INV;
> }
>
> Cheers,
> Wojtek
>
>
>
>
>
nt i=0; i
> Am 11.11.2013 22:44, schrieb Wojciech Lewandowski:
>
> Hi,
>
> I guess answer to main question would be go ahead and add this.
>
> Okay, I just wanted to make sure they are not left out intentionally.
>
> But I just want to write about something else here.
Hi,
I guess answer to main question would be go ahead and add this. But I just
want to write about something else here. If you attach Texture2DMultisample
to Camera you would want to leave the number of samples and color samples
at 0. Thats because these params are used to set up rendering to
mult
I am an author of LISPSM and I do not totally agree with your Robert. I
know cases where LispSM or MSM still works better (flight sims with
sparsely filled frustum). I admit LispSM has many weak points so usually do
not respond to your comments but I just snapped. On that particular issue I
believe
Hi,
Hmm, still have doubts. Because of uppercase String name yu just wrote.
std::String does not exist. I would be ok, though, if you wrote you did
declare it as std::string (lowercase) ;-). But lets assume you did just
that and it still does not work, so then I would suggest to enter setText
call
Hi,
Its just a guess, but I believe your call:
text->setText("This is the first line \n This is the second line");
is done implicit conversion to std::string and calling following method:
TextBase::setText( const std::string & );
so in your code I would try declaring str variable as std::stri
Hi Jan,
This looks like interesting problem to debug ;-P but unfortunately I am
really swamped. At least for month if not more.
My hypothesis:
ConvexPolyhedron is bascially a frustum sculpted into convex volume which
is build from many cuts by various planes defined by scene bounding boxes,
main
for frequencies in generation of PhilipsSpectrum from Tessendorf
paper.
Wojtek
2013/7/3 Wojciech Lewandowski
> Hi, Will (Mi ?)
>
> I am also curious what will Kim answer.
>
> I have not studied osgOcean thoroughly and never used it in practice
> except for few test runs. But I
Hi, Will (Mi ?)
I am also curious what will Kim answer.
I have not studied osgOcean thoroughly and never used it in practice except
for few test runs. But I will want to share some of my observations I made
long time ago when I worked on my own Tessendorf paper implementation. We
all are practica
Hi Frank,
Could be something entirely different but have you tried setting empty
program (= activating fixed pipeline) with default ON attribute ?
ie:
ss->setAttribute(new osg::Program);
We were using that approach to turn off Shaders in LightPoints.
Cheers,
Wojtek Lewandowski
2013/2/13 Fr
I was summoned so I respond. Version of DDS plugin before my additions was
using this code to compute number of mipmaps (see revision 10369 of
ReaderWriterDDS.cpp ):
//debugging messages
> float power2_s = logf((float)s)/logf((float)2);
> float power2_t = logf((float)t)/log
Hi Robert,
With current trunk I had an error while compiling osg/Image.cpp for IOS
simulator / GLES2. Symbol GL_RGBA16 was missing. Adding #define GL_RGBA16
0x805B to Image header solves the problem. Image header file attached. Also
sending this post to submissions' forum.
Cheers,
Wojtek Lewandow
Hi, Dario
0: Ops I was sure these methods are available Thats awkward ommission
considering how old this technique is. We probably should add them. But as
a temporal workoaround you can derive your own class from LispSM and add
proper setter and getter for polygon offset...
1: Yes "closed" wa
Hi, Dario,
LispSM is setup by default to cast shadows using light space backfacing
polygons. That approach works well if models are closed and build with face
culling in mind. If your model does not utilize cull faces (and your truck
looks like that case), all front polygons will cast shadows. So
Hi Garret,
I have not worked on Lispsm for long time but description of your problem
may suggest that my method of obtaining main camera and its projection
matrix may not work as it used to or your setup uses unusual multi channel
master / slave configuration that was not tested so far. I am obtai
Welp... The standard procedure is to set the shaders in the ShadowTechnique
with SetMainVertexShader/ SetMainFragmentShader / SetShadowVertexShader /
SetShadowFragmentShader methods...
>From your initial post I assumed that approch you took is different as its
only a begining step, before further
Hi Dario,
This screen looks correct to me. But it seems that all objects are fully
shadowed. You wrote: "all objects in the scene (a horizontal plane, a cube
and the Light". Does it mean that you draw some Light source model too ? If
so doesn't this model occlude everythning by any chance ?
Cheer
Hi Dario,
Code looks ok to me. Have not tried to build it though. I would check your
light source if its set and found by shadow technique. Shadow Technique may
use default viewer light instead. Also do a test with setDebugDraw( true )
and check if 'cyan on pink' depth texture is generated and cha
Hi Dario,
I am not sure I understood what you have done exactly from your post. So
its hard to say what may be wrong. Perhaps you can post a relevant piece of
the code you wrote and then we will be able to point out what goes wrong...
Cheers,
Wojtek
2012/7/22 Dario Minieri
> Hi,
>
> Hi
>
> I'v
Hi, Garret,
Perhaps the reason for what happens is the part of code inherited from
StandardShadowMap which forces null Program on Shadow RTT rendering.
Perhaps osg::StateAttribute::PROTECT on your animation shader can do the
trick ? You may also try to comment that part and see if helps:
See line
Hi, Kim,
Lispsm in default mode renders back facing polygons (in light space) to
avoid self shadowing of front surfaces. In your case it looks like you
would rather want to use front facing polygons to cast shadows instead.
Normally its not neccessary because back facing normals would cause the
ba
Hi, Frederic,
I was testing similar situation on GeForces more than 2 years ago (I left
the building in the meantime) and honestly don't remember if we have found
'an always working' recipee for this problem. All I remember we were
somehow able to use multiple cards with multiple monitors but hone
e
> texturing on the shader and a textured sample model.
>
> Hope that helps! I would gladly appreciate feedback.
>
> Eduardo
>
>
> On Sat, Apr 21, 2012 at 3:27 AM, Wojciech Lewandowski
> wrote:
> > Thanks a lot Stephan. This is tremendous help. And very encoura
Thanks a lot Stephan. This is tremendous help. And very encouraging. I see
it's time to purchase the dev machine and start practical excercisses ;-)
Thanks again,
Wojtek
2012/4/21 Stephan Huber
> Hi Wojciech,
>
> Am 20.04.12 17:28, schrieb Wojciech Lewandowski:
>
> >
Hi Guys,
We want to port an OSG program to Ipad. This was once written on Windows.
We already gathered some experience on OSG/GLES when porting it to Android.
And now its time for IOS. We are completely fresh on IOS Mac programming,
though. So fresh, we don't even own a Mac for development station
Hi,
These lines limit the textures used for rendering shadow map. Basically
there is no need to render the models with textures when we only render
depth in shadow map. The only exception are textures which can contain
alpha and then models will not render the parts with full transparency. So
the
> ** **
>
> Brad
>
> ** **
>
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Wojciech
> Lewandowski
> *Sent:* Saturday, 17 March 2012 1:59 AM
>
> *To:* OpenSceneGraph Users
> *Subject:* Re:
Hi, Brad,
We have SilverLining source code license. I may find few hours in next week
to look at the problem, if the issue can be reproduced on one of my
machines (ie Nvidia GF580/GF9400 or GF540M). I would like to have as much
info as possible to replicate the issue, though. I would like to know:
maybe you guys should consider passing in your own shaders (copied from
2.8 version) to make that look right again...
Cheers,
Wojtek Lewandowski
2011/12/1 Wojciech Lewandowski
> Hi, Michael,
>
> Well, then I guess addition of gl_FrontLightProduct[0] should be
> uncomented. And tha
Hi, Michael,
Well, then I guess addition of gl_FrontLightProduct[0] should be
uncomented. And thats a missing piece of the puzzle... SVN Blame shows that
Robert commented it in 12737 rev on 29th of July. I guess its time to ask
Robert what to do with this.
Cheers,
WL
2011/12/1 Michael Guerrero
Hi Sebastian,
Unfortuantely I do not have enough time to get as deep as neccessary into
this complex problem you are considering. There could be many approaches to
integration of deffered shading with OSG. And I guess algorithms and data
structures used in such implementations would most probably
Hi Michael,
Haven't you just skipped addition of gl_FrontLightProduct[0].ambient which
should contain contribution of light 0 ambient * material ambient ? So
final colorAmbientEmissive is gl_FrontLightModelProduct.sceneColor
+ gl_FrontLightProduct[0].ambient. This should produce
similar colorAmb
Hi Cyril,
None of the View Dependent Techniques was using Ambient Bias before. So
thats not the case here I suppose.
I am not sure if thats "it" but look at the shaders located in
StandardShadowMap.cpp. I believe that Robert has switched the shadow
shaders to use only fragment shaders somewhere b
Hi, Everyone
This the response I got from NVidia:
> It turns out this issue is already fixed in our upcoming 290.xx drivers. We
> expect a beta driver from this branch to be released sometime in the next few
> weeks.
>
> Thanks for the very easy repro and very thorough detailing of the proble
Hi, Martin
I am assuming you are complaining about limitiation of techniques derived
from ViewDependentShadowTechnique. If thats a such huge problem for you then
you may try to fix ViewDependentShadowTechnique to use RenderStage ptr
instead of CullVisitor ptr to index ViewDependentData. That r
Hi, Guys,
Bug reported to NVidia. Will keep you posted on progress. See my report
below:
WL
From: Wojciech Lewandowski
Sent: Saturday, October 15, 2011 2:10 PM
To: devsupp...@nvidia.com
Subject: OpenGL VBO bug in Windows (OpenSceneGraph)
Dear Dev Support,
We have recently isolated an issue
Hi, J-S
Hehe, do you read my mind ? You posted the answer before my question I
arrived on the list.
I will send them broken model then. If they have osg installed, they could
easily see the OpenGL calls with glDebuger.
Cheers,
Wojtek Lewandowski
-Oryginalna wiadomość-
From: Jean-Séb
n Behalf Of J.P.
Delport
Sent: donderdag 13 oktober 2011 7:39
To: OpenSceneGraph Users
Subject: Re: [osg-users] VBO Bug ?
Hi,
On 12/10/2011 18:45, Wojciech Lewandowski wrote:
So if you are on Linux and have a
minute please let me know how the test passed on your machine ;-)
tested on two more
seems like a
problem is somehow triggered when vbo index range gets close to max value
addresable on ushort.
Cheers,
Wojtek Lewandowski
From: PP CG
Sent: Wednesday, October 12, 2011 6:20 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] VBO Bug ?
On 12.10.2011 15:55, Wojciech
Hi,
You will probably need to dive into osgShadow code with debugger. I would
recommend using osgShadow::ShadowMap for this purpose. Its probably simplest
from depth shadow mapping techniques. I would put the breakpoint at start
of void ShadowMap::cull(osgUtil::CullVisitor& cv) method and wou
Hi,
This looks like you are using LispSM vraiant based on computation of Draw
Bounds around rendered scene. Draw Bounds means that result of Draw phase ie
prerenderd depths of the scene is used to compute volume of scene which will
receive shadows. Debug HUD in lower left corner displays two
Hi Cyril,
I have finally looked at your example. You set up an omnidirectional light
which was very close to the scene and this case cannot really work well
using single shadow map. Omni directional light may work if it can be
approximated with spot light and set up fairly narrow (< 120) field
Hi Cyril,
Sorry I am on vacations and have not spotted your question before. Also I
will not be able to look at the source code before I get back next week.
MinimalShadowMap or MinimalCulllBoundsShadowMap should work correctly with
large LightMargin. Does your light source is an infinite direc
Hi Brad,
Did you forget to call
texture->setShadowComparison(true) ?
Its neccessary for shadow2D and shadow2DProj to work.
setShadowComparison( true ) is equivalent to OpenGL:
glTexParameteri( TextureId , GL_TEXTURE_COMPARE_MODE_ARB,
GL_COMPARE_R_TO_TEXTURE_ARB );
Cheers,
Wojtek
-
Hi, Roger,
You might have 16 texture units but only 8 texture coords. And fixed
pipeline texgens of course can be set up to 7th stage.
Cheers,
Wojtek
-Oryginalna wiadomość-
From: Roger James
Sent: Wednesday, July 06, 2011 7:50 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-
Hi Linda,
Your code looks correct to me. Your shader does the texture lookup at 0,0,0
coord is there a chance that your test1.bmp picture is black in the corner ?
Or its res differs than 128x128 so loading them does not work or leaves
some empty space ?. You may try to run the example code f
Hi Kris,
Unfortunatelly I cannot offer you a working code example. But I have few
observations that could help I believe. For sure you have an error in
glBindTexture call. It should be called with GL texture object id. You can
obtain it from your RTT texture with
getTextureObject(state->getCo
Hi,
I am glad you could solve it. I was not aware of _renderOrderNum index. So
thanks, I have learned important new stuff today ;-)
I guess you had to override either Ocean or LispSM techniuque already. So
you may set _renderOrderNum in overriden code. Depending on which one you
overrode, I
Hello !
I hope you don't mind I address you directly for this question, but as you
implemented the view-dependent shadow techniques, you are best placed to
answer it.
Well... we will see if I will be able to help here.
I am currently investigating a problem that seems to be caused by the
or
Hi,
On 5/16/2011 12:55 PM, Paul Martz wrote:
So I always recommended using Slaves cameras
instead of Nested cams because they have their own CullVisitors. If I
would
design this today, instead of CullVisitor I would probably use
RenderStage to
index view resources.
Understood. This is View
Hi Paul,
What I know for certain is this: all shadow techniques stemming from
ViewDependentShadowTechnique (StandardShadowMap, MinimalShadowMap, LispSM)
are not compatible with nested cameras. And its a design flaw. Basically all
these techniques allocate resources per View and views are recog
1 - 100 of 597 matches
Mail list logo
