Hi Nick,
I haven't worked with osgShadow for over a year so it's not fresh in
my mind. There are mechanisms for override the state management in
osgShadow but I don't recall how widely they are implemented amongst
the shadow techniques.
With the proposed change, with the explicit
Hi Robert,
thanks for the reply. Well, I spent quite a good amount of time to
understand how it works and it all points to the StandardShadowMap, the
call I posted. This shadowmap technique allows you to attach shaders to it
through the interface, but the program is set localy again for a local
Hi Robert,
I posted a while ago a question how to get the osg::Program associated with
the shaders from the StandardShadowMap in order to extend. And it is localy
defined as you can see in the code. However I found a workaround, by
extending the ShadowingScene and catch the StateSet from the Cull
Hi NIck,
On 1 May 2015 at 19:11, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
Hi again Robert,
I took a closer look into ShadowedScene::traverse and you are right. The
reason to force osg::Group::traverse is to allow to call this from the
ShadowedTechnique, to avoid recursive
Okay ... if you find in any case 5 minutes, attached are the proposed mods.
Thanks as always!
Nick
On Fri, May 1, 2015 at 8:16 PM, Robert Osfield robert.osfi...@gmail.com
wrote:
Hi NIck,
On 1 May 2015 at 19:11, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
Hi again Robert,
Hi again Robert,
I took a closer look into ShadowedScene::traverse and you are right. The
reason to force osg::Group::traverse is to allow to call this from the
ShadowedTechnique, to avoid recursive calls of the same.
So I am going to ask if you can expose the local osg::Program through an
Hi Nick,
There isn't any way of me judging changes I haven't seen. In general
if there is part of the OSG that isn't able to do what a users need it
to do but a small change that is consistent with the overall design
can achieve this then I'll be open to considering it to be merged.
However, I
Hi Robert,
let me do the changes then and I will send them to You so You decide. And
thanks!
Nick
On Thu, Apr 17, 2014 at 10:44 AM, Robert Osfield
robert.osfi...@gmail.comwrote:
Hi Nick,
There isn't any way of me judging changes I haven't seen. In general
if there is part of the OSG that
Hi Robert,
I am not sure if you are familiar with this code ( I bet You are ;-) ). I
have a case where I want to mix shaders with the one that are provided to
this class and I need access through the interface to the osg::Program
which holds these shaders and it is instantiated locally in the
Hello,
Being a software engineer, I did my final project study in 3D animation and
virtual reality visualization using OpenSceneGraph. Today I want to prepare my
thesis in augmented reality. I'm looking for a good topic to prepare in 3 years.
What are the themes of current research linking
Hi,
On Wed, Oct 23, 2013 at 10:51 AM, Mohamed Alji osgfo...@tevs.eu wrote:
**
Hello,
Being a software engineer, I did my final project study in 3D animation
and virtual reality visualization using OpenSceneGraph. Today I want to
prepare my thesis in augmented reality. I'm looking for a
Hi,
Very good point, you are right. OSG is a technology , I have to see it as a
tool in my research.
Where can I find an open AR problem ? where am I supposed to look ? How to do
that ?
ps: I found a thesis director, I will speak to him later today.
Thank you!
Cheers,
Mohamed
Hi,
On Wed, Oct 23, 2013 at 12:28 PM, Mohamed Alji osgfo...@tevs.eu wrote:
**
Hi,
Very good point, you are right. OSG is a technology , I have to see it as
a tool in my research.
Keep that in mind - it is easy to slip into the engineering mindset and
just do some coding or whatever - but
Thank you, Robert!
it worked well.
for the record, the correct call is made on osg::View
Code:
_view-requestRedraw()
I am puzzled how i could have missed the method in the sources :?
Cheers,
Andrey
--
Read this topic online here:
Hello world!
Until recently i had been using
Code:
_viewer-setRunFrameScheme(osgViewer::ViewerBase::CONTINUOUS);
but then i switched to
Code:
_viewer-setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND);
and now i have a minor problem with window refresh.
This should be fairly simple to do,
Hi Audrey,
I haven't tried exactly what you are doing but you could try :
_viewer-requestRedraw();
This method is inherited from osgGA::GUIActionAdapter.
Robert.
On 26 February 2012 15:31, Andrey Ibe xry...@gmail.com wrote:
Hello world!
Until recently i had been using
Code:
hello world___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
On Fri, Jan 27, 2012 at 9:01 PM, Robert Osfield
robert.osfi...@gmail.com wrote:
...
Curiously running separate contexts via separate applications has in
the past shown good scalability so I suspect the driver contention is
something per application specific.
Along these lines I do wonder if
As a side note:
if you were using vbo's instead of display lists for drawing i think you werent
get into this problem in first place, as with vbos 5500 draw calls would
happily kill your performance even on one screen, so you have to optimize your
models. Nvidia drivers are great at optimizing
Hi Jason -- I agree that the system bus is a likely source of the scaling issue.
It is certainly a single resource that has to be shared by all the GPUs in the
system.
To make a case for bus bandwidth limitation, you might work through the math.
Bb
FPS =
Nw
On 1/27/2012 7:17 AM, Paul Martz wrote:
Sd is the size of the drawing commands in bytes
gDebugger might be able to help you estimate this too.
--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Digital Imaging. OpenGL. Scene Graphs. GIS. GPS.
On 1/27/2012 7:17 AM, Paul Martz wrote:
Bb
FPS =
Nw * Nd * Sd + O
Where Bb is the bus bandwidth in bytes,
Upon rereading this, a few corrections:
Bb
FPS = --
Nw * (Nd * Sd + O)
And note that Bb is bandwidth in bytes/sec,
On 01/27/2012 04:38 AM, Sergey Polischuk wrote:
As a side note:
if you were using vbo's instead of display lists for drawing i think you werent
get into this problem in first place, as with vbos 5500 draw calls would
happily kill your performance even on one screen, so you have to optimize
Hi, Paul,
As Tim pointed out earlier, the more limiting resource is likely to be
lock contention in the NVidia driver instead of bus contention.
Note that Bb is going to be 4000 MB/sec (500 MB/sec * 8), per Quadroplex
(PCI-e 2.0 8x) on the NIST machine. On my system I have an X58 chipset,
Sorry, I was going off your post that read This leads me to believe that bus
contention was causing the lack of scalability. I was just trying to outline a
way to validate that suspicion. If you've already ruled out bus contention, then
disregard my post.
-Paul
On 1/27/2012 11:40 AM,
On 01/27/2012 02:12 PM, Paul Martz wrote:
Sorry, I was going off your post that read This leads me to believe that bus
contention was causing the lack of scalability. I was just trying to outline a
way to validate that suspicion. If you've already ruled out bus contention, then
disregard my
Hi All,
I haven't chipped in so far as I haven't really too much to add to the
investigation. My sense from own tests and looking at others over the
years is that looks to be contention in the drivers that leads to poor
scaling. Reducing the amount of data and commands being pushed in
each
Hello Jason,
On Jan 27, 2012, at 1:37 PM, Jason Daly wrote:
On 01/27/2012 02:12 PM, Paul Martz wrote:
Sorry, I was going off your post that read This leads me to believe that bus
contention was causing the lack of scalability. I was just trying to
outline a
way to validate that suspicion.
On 01/27/2012 04:17 PM, Doug McCorkle wrote:
We run a very similar system with 5 quadro cards and do not run into these
problems with very large models. We are using VR Juggler though. I mention this
because it would be very straight forward to use one of the sample OGL VR
Juggler examples
On Jan 27, 2012, at 4:12 PM, Jason Daly wrote:
On 01/27/2012 04:17 PM, Doug McCorkle wrote:
We run a very similar system with 5 quadro cards and do not run into these
problems with very large models. We are using VR Juggler though. I mention
this because it would be very straight forward
Hi, JP,
On 01/26/2012 01:53 AM, J.P. Delport wrote:
very interesting and thorough investigation. I can't really add anything
and unfortunately don't have representative hardware to test on. It
would be interesting to see if different bus configs
(motherboards/chipsets) make any difference.
: Thursday, January 26, 2012 6:49 PM
Subject: Re: [osg-users] Request for input
Hi, JP,
On 01/26/2012 01:53 AM, J.P. Delport wrote:
very interesting and thorough investigation. I can't really add anything
and unfortunately don't have representative hardware to test on. It
would be interesting
On Wed, Jan 25, 2012 at 10:59 PM, Jason Daly jd...@ist.ucf.edu wrote:
Hi, all,
This is a general request to the community for some advice and expertise.
This is a bit lengthy, but if you can spare a few minutes to look over this
and send along your thoughts, we would really appreciate it.
On 01/26/2012 01:01 PM, Peter Kilpatrick wrote:
Hello,
This may be relevant:
Memory Speed, QPI and Multicore
http://www.masm32.com/board/index.php?PHPSESSID=afe5222fb85c769a44da28f1eb5d4b82topic=17296.0
Hi, Peter,
So the lesson there is to ensure that your RAM is running at optimal
On 01/26/2012 01:02 PM, Tim Moore wrote:
That is what I found at the time of that thread, testing with some
models supplied by NIST. Newer hardware is highly optimized for
massive geometry.
For the record, I don't think the problem is bus contention, but lock
contention in the NVidia driver.
Hi,
On 26/01/2012 20:02, Tim Moore wrote:
Btw, the Linux tool oprofile is mentioned later in the thread, but I
find the newer tool perf to be more useful.
niiice, new tools :) I've used gprof2dot with oprofile before to get a
nice graphic view of execution. I see it supports perf too now,
Hi, all,
This is a general request to the community for some advice and
expertise. This is a bit lengthy, but if you can spare a few minutes to
look over this and send along your thoughts, we would really appreciate it.
I've been working on a project for NIST recently. For background, you
On 01/25/2012 04:59 PM, Jason Daly wrote:
Hi, all,
This is a general request to the community for some advice and
expertise. This is a bit lengthy, but if you can spare a few minutes to
look over this and send along your thoughts, we would really appreciate it.
I should also mention that the
Hi Jason,
Any thoughts on these issues or other thoughts you could provide would
be very valuable.
I don't have that much to add. I commend you on your investigations, you
really went to the crux of the problem and kept at it until you found
the answer.
The mesh optimizers I've mentioned
Hi,
On 26/01/2012 01:20, Jason Daly wrote:
On 01/25/2012 04:59 PM, Jason Daly wrote:
Hi, all,
This is a general request to the community for some advice and
expertise. This is a bit lengthy, but if you can spare a few minutes to
look over this and send along your thoughts, we would really
Hi Jefferson,
Like Gordon says, if you need the function then the thing to do is
implement it and submit it. I'm not hear to take end users feature
requests and then go a implement them for free. I have bucket load of
work to do, working well over my forty hour week every week, with many
of
I understand.
About my other question then, there is currently no workaround to test
collision between two polytopes? I tried
polytope.contains(polytope2.getReferenceVertexList()) but it doesn't seems
to work either (always returning false). Any other ideas?
On Thu, Dec 4, 2008 at 7:05 AM,
Hello Robert,
Can you please implement a function, in class Polytope, that checks if the
current polytope intersects another polytope? Or is there another way to do
that, and I'm not seeing?
Thanks,
--
Jefferson Pinheiro
___
osg-users mailing list
- Master Tambo Tetsura
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jefferson Pinheiro
Sent: Wednesday, December 03, 2008 3:11 PM
To: OpenSceneGraph Users
Subject: [osg-users] Request: bool Polytope.contains(another_polytope)
Hello Robert
:* Wednesday, December 03, 2008 3:11 PM
*To:* OpenSceneGraph Users
*Subject:* [osg-users] Request: bool Polytope.contains(another_polytope)
Hello Robert,
Can you please implement a function, in class Polytope, that checks if the
current polytope intersects another polytope? Or is there another
Hi Roland,
I've made an update and I am trying to build the Collada plugin (under WinXP
using VS8), I first noticed that you've added some dependencies to it for
the dynamic build :
libxml2 pcrecpp-d pcre-d
I was wondering why do you ask for pcrecpp-d and pcre-d ? It's the debug
versions of the
use the external-libs in the
Collada DOM directory.
--
Roland
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Serge
Lages
Sent: maandag 1 december 2008 11:03
To: OpenSceneGraph Users
Subject: Re: [osg-users] Request
PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Serge Lages
*Sent:* maandag 1 december 2008 11:03
*To:* OpenSceneGraph Users
*Subject:* Re: [osg-users] Request for testing Collada/dae plugin changes
Hi Roland,
I've made an update and I am trying to build the Collada plugin (under
WinXP using
Subject: Re: [osg-users] Request for testing
Collada/dae plugin changes
Hi Roland,
I've made an update and I am trying to build the
Collada plugin (under WinXP using VS8), I first
On Mon, Dec 1, 2008 at 11:31 AM, Smeenk, R.J.M. (Roland)
[EMAIL PROTECTED] wrote:
If I link the DOM dynamically I don't need to set these targets here, right
? (like in the previous version of the CMakeList.txt)
Hmm, not sure.
I am also having links errors like that :
2daeReader.obj :
Hello osg-users,
Robert just merged my changes for the Collada/dae plugin as posted on
osg-submission:
http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph
.org/2008-November/002883.html
You are kindly invited to test the improved plugin.
--
Roland
This e-mail and its
51 matches
Mail list logo
