Re: [osg-users] CUSTOM MESH TEXTURE COORDINATE PROBLEM
Hi, Solution Found... (*texCoords)[j].set((float)k/heightMap->t(), (float)i/heightMap->s()); (*vertices)[j].set( c1*(r+(*heightMap->data(i, k))/10),k, s1*(r+(*heightMap->data(i, k))/10)); (*texCoords)[j+1].set((float)k/heightMap->t(), (float)(i+1)/heightMap->s()); (*vertices)[j+1].set( c2*(r+(*heightMap->data(i+1, k))/10),k, s2*(r+(*heightMap->data(i+1, k))/10)); (*texCoords)[j+2].set((float)(k+1)/heightMap->t(), (float)i/heightMap->s()); (*vertices)[j+2].set( c1*(r+(*heightMap->data(i, k+1))/10), k+1,s1*(r+(*heightMap->data(i, k+1))/10)); (*texCoords)[j+3].set((float)(k+1)/heightMap->t(), (float)(i+1)/heightMap->s()); (*vertices)[j+3].set( c2*(r+(*heightMap->data(i+1, k+1))/10), k+1,s2*(r+(*heightMap->data(i+1, k+1))/10)); ... Thank you! Cheers, Umid -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48422#48422 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building a slimmed down static version of OSG
Hi Preet,
Did you make any progress on this? I'm getting a similar error and I am
stumped. I have a fedora 16 32bit machine with osg 3.0.1 where my code compiles
fine and then I have a fedora 17 64bit machine also with osg 3.0.1 where I get
this undefined reference.
I added a "virtual void requestRedraw(){} ;" to the GraphicsWindowEmbedded
header file just to see what would happen and it compiles but I get a crash
right away on an addChild in Qt land.
Thanks,
David
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=48421#48421
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget Frame borders
Hello Jason, There are pixel gaps in between the corners and borders that make the frame look quite awful. I am guessing there are some ever so slight rounding errors when computing the quad locations. Most often, borders like that come from the default wrapping mode OpenGL uses on textures, which is CLAMP_TO_BORDER. The default border color is black, and for the last pixel in linear interpolation mode OpenGL will interpolate between the last pixel of the texture and the border color, so you get a gray color there. You should set it to CLAMP_TO_EDGE instead (this really should have been the default from the start), which will make OpenGL interpolate between the last pixel and itself, so no border will show. Now, if this is when using osgWidget then it's probably osgWidget loading the images, not you. So you might have to modify osgWidget (and submit the modification :-) ) I think I've used border images like that but always with dark or semi-transparent images, so the border just didn't show in my testing... Otherwise I would have fixed this! :-) Hope this helps, J-S -- __ Jean-Sebastien Guay jean_...@videotron.ca http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] LightPointNode BlinkSequence class modification questions.
Robert, How would you feel about changing the osg::Vec4 BlinkSequence::color(double time,double length) const to virtual? I would like to customize the behaviour of this call but I'm currently unable to because it is inlined and not virtual. Thank you! Cheers, Brad -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48419#48419 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Ideas about a resource system, and deferred rendering framework
Hi Wang, might be not quite a significant point, but osg based Flightgear has a ongoing Project Rembrandt http://wiki.flightgear.org/Project_Rembrandt it has some similar things done, so could serve for inspiration. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ideas about a resource system, and deferred rendering framework
I've been doing some thought of this kind of stuff myself, and it was actually a part of the reason I was considering hopping over to Ogre3D. I would actually suggest however taking a look at Light Indexed Deferred Rendering or Inferred Rendering as possible alternate implementations however, which address some of the issues deferred rendering has at the expense of a little bit of performance. There is something else to take in to account performance wise. It may be wise to design the resource manager in a data-orientated way, meaning to store all of a variable's values, such as a vec3's x value, in a single array. dtEntity's properties class seems to do this. This will assist in preventing cache misses, and thus increase the speeds of going through data. I would suggest however using memsize types where possible (I.E. using size_t instead of unsigned int), which will eat up slightly more memory, but will also help prevent memory allocation errors on 64 bit platforms. Cheers, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48415#48415 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ideas about a resource system, and deferred rendering framework
Thanks Bryan, Yes, I paid close attention to osgPPU since it appeared. I believe it would be very helpful for me to design the framework, although the script system we are going to use may differ. :-) Wang Rui 2012/6/21 Thrall, Bryan > Wang Rui wrote on 2012-06-21: > > 2. A rendering framework uses one or more techniques, passes, and > connect > > their inputs/outputs for complex render work. It can also be recorded > by the > > resource system and is implemented as a group node in the scene graph, > > which performs actual forward/deferred rendering work. > > It seems like osgPPU already does this; you might want to look at it to > see if it meets your needs, or at least could inspire what you're doing. > > Hope this helps! > -- > Bryan Thrall > Principal Software Engineer > FlightSafety International > bryan.thr...@flightsafety.com > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] osgRecipes: Integrate OSG with almost everything :-)
Hi Christian, Thank you. So I would add osgrvo2 to this new project as soon as possible, with your copyrights preserved. Wang Rui 2012/6/21 Christian Buchner > Permission granted to use my osgrvo2 integration example (massive > agent simulation) > > Christian > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ideas about a resource system, and deferred rendering framework
Wang Rui wrote on 2012-06-21: > 2. A rendering framework uses one or more techniques, passes, and connect > their inputs/outputs for complex render work. It can also be recorded by the > resource system and is implemented as a group node in the scene graph, > which performs actual forward/deferred rendering work. It seems like osgPPU already does this; you might want to look at it to see if it meets your needs, or at least could inspire what you're doing. Hope this helps! -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Node visitor pattern
Hi. I'm going to use OSG as one of my game engine components. Currently I have Timer singleton. Classes that wish to be notified regularly should inherit from TimerListener and add themselves to the queue like Timer->addListener(this, 30); where 30 is 30 milliseconds, i.e., they will be notified approximately each 30 milliseconds. In listeners I do 'animations' (moving, scaling, etc). In OSG, however, each node gets traversed, even several times. Currently I'm unsure how to implement my new Timer with OSG. The single deciding Timer class seems to require less power, since it doesn't call each listener each frame, instead, it knows when to call each listener and only does it when necessary. May be I'm misunderstanding current visitor pattern? May be it's really necessary to traverse each listener each frame and let each listener decide? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgWidget Frame borders
(I am reposting this because of a mailing list error I received the first time) I am having trouble with osgWidget::Frame and the included osgwidgetframe example program. There are pixel gaps in between the corners and borders that make the frame look quite awful. I am guessing there are some ever so slight rounding errors when computing the quad locations. See attached image. Are there any work arounds? Thanks, Jason -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48409#48409 <>___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] osgRecipes: Integrate OSG with almost everything :-)
Permission granted to use my osgrvo2 integration example (massive agent simulation) Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ideas about a resource system, and deferred rendering framework
Great and valuable design and works! 06,21,2012 在2012-06-21，"Wang Rui" 写道: -原始邮件- 发件人: "Wang Rui" 发送时间: 2012年6月21日 星期四 收件人: "OpenSceneGraph Users" 主题: [osg-users] Ideas about a resource system, and deferred rendering framework Hi Robert, hi all, During the past few days, I was thinking of implementing a resource system, as well as a rendering structure which could support both forward and deferred rendering for OSG. This could help developers design complex materials and effects, test cutting-edge GPU techniques, and implement multi-pass / deferred rendering pipelines with user-friendly interfaces or even a readable script format. Similar work were already done in some game engines like Ogre3D, CryEngine and Unreal, and I now plan to work out something with the same power and can fit our OSG users much better. :-) My initial thoughts are: 1. A resource system records all the resource used in the rendering pipeline, including textures, state attributes, shaders, uniforms, camera parameters, and semantics (not used in GLSL, but very useful IMHO). Resource can be referred by other resource, or obtained from APIs to be altered. It can be recorded in an XML-based format for reading/writing, and external uses. 2. A rendering framework uses one or more techniques, passes, and connect their inputs/outputs for complex render work. It can also be recorded by the resource system and is implemented as a group node in the scene graph, which performs actual forward/deferred rendering work. 3. Some in-built techniques and passes can help implement some complex effects on customized scene quickly. Common ones I planned include HDR, SSDO, godrays, depth of field, motion blur, lensflare, color grading and FXAA. A benchmark could be developed first to show how the framework works. 4. Reader/writers could be developed then to convert DAE, CGFX, or even other game engine scripts into OSG native rendering pipelines, which will greatly help migrations from other engines. The resource system itself is actually abstract and can be extended to contain whole scene information later, so it could be placed in the osgDB library. And the new rendering pipeline, which can totally replace current osgFX functionlities, can be placed in osgFX and rendering resource management will be done here, too. I'm glad to work with others who has interests in such an idea, and hope an initial version could be finished before OSG 3.2. For the first stage I will borrow some code from the osgPostEffects library in my experimental osgXI project, to quickly build the low-level APIs of the framework. But anyone who have better ideas, or could contribute some code or effects will be really appreciated. Cheers, Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ideas about a resource system, and deferred rendering framework
Hi Rui, Great timing. I've been wondering about the value of developing a high level scene effects library for the OSG that would sit between the viewer and model scene graph to enable effects such as you've mentioned that take advantage of viewer level threading as well integrate with existing OSG effects like libraries like osgShadow. I haven't got to the point of spec'ing up what form this library might take, let alone getting down to the design and prototyping stage so I suspect you'll be further along than myself on it so look forward to hearing more about what you are proposing/working on. Getting these feature in for OSG-3.2 might be possible but personally I'd like to get 3.2 sooner rather than later so would suggest aiming for after 3.2. However, as much as I wanted to get 3.2 out already my work and personal life have rather swept me off my feet in the last six months so getting on to 3.2 has taken me rather longer than I ever wanted... Over the next week I'll be taking stoke of all my outstanding work and what is planned for the next few months so will have a think about 3.2 as part of this. I can't make a 3.2 without the community so it's something will need to fit in with availability of others as well. For now I'd suggest just concentrate on your proposals and if they fit into 3.2 time frame than all good, if not no worry, we can just aim for 3.4. Cheers, Robert. On 21 June 2012 09:53, Wang Rui wrote: > Hi Robert, hi all, > > During the past few days, I was thinking of implementing a resource system, > as well as a rendering structure which could support both forward and > deferred rendering for OSG. This could help developers design complex > materials and effects, test cutting-edge GPU techniques, and implement > multi-pass / deferred rendering pipelines with user-friendly interfaces or > even a readable script format. Similar work were already done in some game > engines like Ogre3D, CryEngine and Unreal, and I now plan to work out > something with the same power and can fit our OSG users much better. :-) > > My initial thoughts are: > 1. A resource system records all the resource used in the rendering > pipeline, including textures, state attributes, shaders, uniforms, camera > parameters, and semantics (not used in GLSL, but very useful IMHO). Resource > can be referred by other resource, or obtained from APIs to be altered. It > can be recorded in an XML-based format for reading/writing, > and external uses. > 2. A rendering framework uses one or more techniques, passes, and connect > their inputs/outputs for complex render work. It can also be recorded by the > resource system and is implemented as a group node in the scene graph, > which performs actual forward/deferred rendering work. > 3. Some in-built techniques and passes can help implement some complex > effects on customized scene quickly. Common ones I planned include HDR, > SSDO, godrays, depth of field, motion blur, lensflare, color grading and > FXAA. A benchmark could be developed first to show how the framework works. > 4. Reader/writers could be developed then to convert DAE, CGFX, or even > other game engine scripts into OSG native rendering pipelines, which will > greatly help migrations from other engines. > > The resource system itself is actually abstract and can be extended to > contain whole scene information later, so it could be placed in the osgDB > library. And the new rendering pipeline, which can totally replace current > osgFX functionlities, can be placed in osgFX and rendering resource > management will be done here, too. > > I'm glad to work with others who has interests in such an idea, and hope an > initial version could be finished before OSG 3.2. For the first stage I will > borrow some code from the osgPostEffects library in my experimental osgXI > project, to quickly build the low-level APIs of the framework. But anyone > who have better ideas, or could contribute some code or effects will be > really appreciated. > > Cheers, > > Wang Rui > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Mouse events with osgUtil::SceneView
Hi, I must use osgUtil::SceneView because I use VRJuggler. I want to use mouse events with osgUtil::SceneView. With osgViewer, we can write this : viewer.addEventHandler(new osgWidget::MouseHandler(wm)); Is it possible to use this with osgUtil::SceneView? How do I do? Thank you! Cheers, lucie -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48404#48404 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Ideas about a resource system, and deferred rendering framework
Hi Robert, hi all, During the past few days, I was thinking of implementing a resource system, as well as a rendering structure which could support both forward and deferred rendering for OSG. This could help developers design complex materials and effects, test cutting-edge GPU techniques, and implement multi-pass / deferred rendering pipelines with user-friendly interfaces or even a readable script format. Similar work were already done in some game engines like Ogre3D, CryEngine and Unreal, and I now plan to work out something with the same power and can fit our OSG users much better. :-) My initial thoughts are: 1. A resource system records all the resource used in the rendering pipeline, including textures, state attributes, shaders, uniforms, camera parameters, and semantics (not used in GLSL, but very useful IMHO). Resource can be referred by other resource, or obtained from APIs to be altered. It can be recorded in an XML-based format for reading/writing, and external uses. 2. A rendering framework uses one or more techniques, passes, and connect their inputs/outputs for complex render work. It can also be recorded by the resource system and is implemented as a group node in the scene graph, which performs actual forward/deferred rendering work. 3. Some in-built techniques and passes can help implement some complex effects on customized scene quickly. Common ones I planned include HDR, SSDO, godrays, depth of field, motion blur, lensflare, color grading and FXAA. A benchmark could be developed first to show how the framework works. 4. Reader/writers could be developed then to convert DAE, CGFX, or even other game engine scripts into OSG native rendering pipelines, which will greatly help migrations from other engines. The resource system itself is actually abstract and can be extended to contain whole scene information later, so it could be placed in the osgDB library. And the new rendering pipeline, which can totally replace current osgFX functionlities, can be placed in osgFX and rendering resource management will be done here, too. I'm glad to work with others who has interests in such an idea, and hope an initial version could be finished before OSG 3.2. For the first stage I will borrow some code from the osgPostEffects library in my experimental osgXI project, to quickly build the low-level APIs of the framework. But anyone who have better ideas, or could contribute some code or effects will be really appreciated. Cheers, Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in osgGA::EventQueue?
Hi Anthony,
Thanks for the information. Could you try the svn/trunk version of
the OSG? This week I checked in refactor of the
Viewer::advance()/eventTraversals() methods so that the call to
EventQueue::frame() is done after the events are collected from the
graphics windows. This refactor was done to address an issue with the
mouse position and button mask not being passed onto to the frame
event right away (it was delayed by a frame in 3.0.x). This change
will also affect the event timing a little, I can't say whether it'll
effect the issue you are seeing yet as I haven't yet reproduced it,
but it would sure be worth checking.
Robert.
On 21 June 2012 07:40, I-Nixon, Anthony D wrote:
> I should have mentioned that :-) 3.0.1 on VC 2010 (64 and 32 bit)
>
> You can see the symptom with osgViewer launched with a large model ... if you
> step through the first time takeEvents() is called, there will be events with
> a time higher that the cut-off time - but only fractionally. Since the delta
> is so small it only takes a few frames before event processing starts. I
> think it has a lot to do with the order of object construction.
>
> I our app the EventQueue seems to get constructed a lot earlier in the
> loading process. Since EventQueue's constructor sets _startTick to the time
> at construction, some events get added, and then setStartTick() is called
> again, that is what causes the problem.
>
> We have upgraded from 2.9 to 3.0.1 and also osgEarth 2.0 to 2.2. We
> certainly didn't see the problem with the older versions - maybe it is an
> issue that is only being exposed due to something in osgEarth 2.2.
>
> Anthony
>
> -Original Message-
> From: osg-users-boun...@lists.openscenegraph.org
> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
> Osfield
> Sent: Wednesday, 20 June 2012 6:15 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Bug in osgGA::EventQueue?
>
> Hi Anthony,
>
> I don't have any answers from a first read through, and it's not a problem
> that's been reported as far as I can recall off the top of my head, so it'll
> probably require a code review of the relevant code and discussion to spot
> what might be amiss. Which version of the OSG are you using? Has the bug
> appeared when moving between OSG versions or changing your usage model of the
> OSG?
>
> Robert.
>
> On 20 June 2012 06:28, I-Nixon, Anthony D wrote:
>> Hi Everyone:
>>
>>
>>
>> I'm seeing behavior in my application whereby an osg Window will come
>> up, but won't respond to any events for a few (sometimes 10 or more seconds).
>> Rendering is happening during this time, but no event processing.
>>
>>
>>
>> I tracked it down to the following:
>>
>>
>>
>> 1. The event queue is constructed and initializes _startTick
>>
>> 2. Some events are pushed onto the queue (not explicitly, could
>> be mouse move, etc)
>>
>> 3. Some time passes (generally related to model loading - we are
>> using
>> osgEarth)
>>
>> 4. Rendering starts and calls setStartTick() on the event queue
>> with a new time.
>>
>> 5. takeEvents() is called during event traversal, but because the
>> startTick has been reset, the top event is in the "future" and
>> takeEvents() returns nothing.
>>
>> 6. Eventually enough time passes so that the event is no longer
>> in the "future" and event processing starts happening.
>>
>>
>>
>> The time that the stall lasts for is clearly related to how long step
>> 3 takes - which can be lengthy when osgEarth is fetching stuff off the
>> network.
>>
>>
>>
>> I fixed it by clearing out the events when setStartTick is called, viz:
>>
>>
>>
>>
>>
>> void EventQueue::setStartTick(osg::Timer_t tick)
>>
>> {
>>
>> OpenThreads::ScopedLock
>> lock(_eventQueueMutex);
>>
>> // Since setting the start tick effectively invalidates the time
>>
>> // of any events already in the queue, clear it out
>>
>> _eventQueue.clear();
>>
>> _startTick = tick;
>>
>> }
>>
>>
>>
>> I haven't got a sample that reproduces the behavior, but it seems to
>> make sense that if the startTick is reset, all the existing events are toast?
>> I'm not sure why no one else has seen this - maybe our usage pattern
>> is different from the norm?
>>
>>
>>
>> Cheers
>>
>>
>>
>> Anthony
>>
>>
>>
>> Anthony Nixon
>>
>> Modelling & Simulation Architect
>>
>> Systems Analysis Laboratory (SAL)
>>
>> Strategic Development & Experimentation - International
>>
>> Boeing Defence Australia Ltd
>>
>>
>>
>>
>>
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
>> org
>>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> osg-
[osg-users] ViewDependentShadowMap improvements
Hi Wang In your latest submission update, there is the possibility to set splitvalues. I somehow have a hard time to figure out how to use it. In my settings I calculate shadows up to 500 m max distance, with two shadows for my sun-light. Can't I just say that I want a shadowmap going from 0..100m and the second one covering the rest up to 500m? How do I have to set the splitvalues to achieve this? With the different shadow maps I expect the scene to be culled in each shadow pass according to the split distance said. This means for me that I my first split is pretty close to the viewer I have my first shadow map working at a high resolution for close objects. The further I move the split value, the more triangles are taken into that specific shadow pass... Hope you can explain it in some more detail... Regards Daniel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
