The OpenSG Scenegraph

On 2010-01-23 22:10, Carsten Neumann wrote:
>     Hello Georg,
>
> Georg Wöß wrote:
>> I know there is the important discussion about "OpenSG going down the 
>> drain?" and therefore my problem was forgotten.
>>
>> Have anybody a idea to solve my problem or detect some error in my code?
>
> sorry for the delay, while Marcus was looking at this (thanks Marcus!) 
> I was just sitting on the sidelines, since he has more experience with 
> using Qt + OpenSG anyway.
> It took me a moment to get my 1.8 to compile with the Qt4 stuff 
> enabled (see the other thread), but now I can load your models with 
> testPassiveQT4 and they show up normally (screenshot attached).
>
> Are you using the 1.8 release or do you have a more recent CVS 
> checkout? If its a release I'd recommend trying to upgrade, there have 
> been a bunch of fixes since 1.8 was released and it might just solve 
> the problem. Another alternative would be to use an OpenGL debugger 
> (e.g. bugle, glIntercept) and look if you can spot any relevant 
> differences between your glut and qt programs.
>
>     Cheers,
>         Carsten

Hello,

I have now compiled the current CVS version of OpenSG1.8 and tried the 
testPassiveQT4 example from the OpenSG source and my own samples but the 
problem still exists. Furthermore I tried it with Ubuntu 9.10 in a 
VirtualBox and reinstalled Archlinux on my machine to exclude any wrong 
system configurations. The version of Qt I am using is 4.5.3.

Have anybody an other idea which I could try to solve the problem than 
debug the OpenGL statements with Bugle or some other OpenGL debugger?


Cheers,
     Georg

P.S. The Qt paths of the patch correspond to the paths on my linux 
installation (archlinux). Before I used this instruction ( 
http://vijaymichaeljoseph.blogspot.com/2009/10/compiling-opensg-with-qt4x.html 
) to compile OpenSG with QT4 support.

Hi David,

all of the logos are really great, congrats to all the people working on them! 
Especially I like group a  top left and group d top left. The last one is my 
personal favorit ;-) Just my 2 cent.

Cheers,
Christoph

On Samstag, 23. Januar 2010 01:43:08 David Kabala wrote:
> Here are some of the Logo/Banner concepts that have been produced.
> 
> Mike Rinnan
> <--Group A-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/Mike_open%20sg2.jpg<http:
> //www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/Mike_open%20sg2.jpg>
> 
> Amy Dixon
> Izaak Moody
> <--Group B-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OSG2.jpg<http://www.vrac.
> iastate.edu/%7Edkabala/OpenSG_logos/OSG2.jpg>
> 
> Amy Dixon
> <--Group C-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OpenSG.jpg<http://www.vra
> c.iastate.edu/%7Edkabala/OpenSG_logos/OpenSG.jpg>
> 
> Will Schneller
> <--Group D-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OpenSG_Logos_Version1.jpg
> <http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/OpenSG_Logos_Version1.
> jpg>
> 
> 
> Please let us know what you think.
> 
> Thanks,
> David Kabala
> 
> On Sun, Jan 17, 2010 at 1:40 AM, Dirk Reiners <dirk.reiners@...:
> >        Hi David,
> >
> > On 01/13/2010 10:44 AM, David Kabala wrote:
> > > OpenSG dev team, and OpenSG users,
> > >
> > > In light of the recent discussions on OpenSG 2, some of my artist
> > > friends would like to contribute some ideas for an OpenSG branding
> > > logo/icon.  If some of these icon/logos are acceptable, then we would
> > > love to contribute them.
> >
> > Sounds great. Carsten is right that it's not the most pressing need, but
> > if your
> > artists have the time it would be time well spent.
> >
> > > Would this be welcome/needed/important?
> >
> > I think so. The Beetle is nice, and I like the spirit of it, but it's
> > getting old...
> >
> > > What,if anything, would you like to see for the logo?
> >
> > Honestly I'm pretty open. Given that one of our core distinguishing
> > factors is
> > multi-threading something threaded might be interesting, but other than
> > that I'm
> > flexible.
> >
> > > On the technical side, we are interested in making the logo in the svg
> > > format to allow for scaling.
> >
> > SVG would be fine, we can always bake it into an image if needed.
> >
> > Thanks
> >
> >        Dirk
> >
> >
> > -------------------------------------------------------------------------
> >----- Throughout its 18-year history, RSA Conference consistently attracts
> > the world's best and brightest in the field, creating opportunities for
> > Conference
> > attendees to learn about information security's most important issues
> > through
> > interactions with peers, luminaries and emerging and established
> > companies. http://p.sf.net/sfu/rsaconf-dev2dev
> > _______________________________________________
> > Opensg-users mailing list
> > Opensg-users@...
> > https://lists.sourceforge.net/lists/listinfo/opensg-users
>

So I wanted to add some of my own opinions on the concepts.

On Fri, Jan 22, 2010 at 6:43 PM, David Kabala <djkabala@...> wrote:

> Here are some of the Logo/Banner concepts that have been produced.
>
> Mike Rinnan
> <--Group A-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/Mike_open%20sg2.jpg<http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/Mike_open%20sg2.jpg>
>

Group A:
This set of concepts is professional looking. I like the shape, and the use
of a
tree-like grouping of data assembly.  However, I feel that is "feels" a lot
like Microsoft Windows and corporate branding.  Not that this is necessarily
a bad thing.  I would like to see some concepts around this set with
different color pallets.


> Amy Dixon
> Izaak Moody
> <--Group B-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OSG2.jpg<http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/OSG2.jpg>
>

Group B:
I really like how these concepts are on-par with some other modern
branding.  The style feels similar to Android OS, Apple applications, and
even Firefox branding(a little).  This group is my favorite, as I feel it is
in line with other modern branding, is really recognizable, and could be
used successfully for marketing.


>
> Amy Dixon
> <--Group C-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OpenSG.jpg<http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/OpenSG.jpg>
>
> Will Schneller
> <--Group D-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OpenSG_Logos_Version1.jpg<http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/OpenSG_Logos_Version1.jpg>
>
>
Group D:

I like the professional look of these logos.  I feel that they aren't as
memorable as Group A-C, but could be refined to get to that point.

In conclusion, I would be happy with most of these designs, with may
favorites being group B.  I would like to see further revisions of  Group
A,B, and C with some other suggestions, comments from other OpenSG users.

Thanks,
David Kabala

>
> Please let us know what you think.
>
> Thanks,
> David Kabala
>
>
> On Sun, Jan 17, 2010 at 1:40 AM, Dirk Reiners <dirk.reiners@...:
>
>>
>>        Hi David,
>>
>> On 01/13/2010 10:44 AM, David Kabala wrote:
>> > OpenSG dev team, and OpenSG users,
>> >
>> > In light of the recent discussions on OpenSG 2, some of my artist
>> friends
>> > would like to contribute some ideas for an OpenSG branding logo/icon.
>>  If
>> > some of these icon/logos are acceptable, then we would love to
>> contribute
>> > them.
>>
>> Sounds great. Carsten is right that it's not the most pressing need, but
>> if your
>> artists have the time it would be time well spent.
>>
>> > Would this be welcome/needed/important?
>>
>> I think so. The Beetle is nice, and I like the spirit of it, but it's
>> getting old...
>>
>> > What,if anything, would you like to see for the logo?
>>
>> Honestly I'm pretty open. Given that one of our core distinguishing
>> factors is
>> multi-threading something threaded might be interesting, but other than
>> that I'm
>> flexible.
>>
>> > On the technical side, we are interested in making the logo in the svg
>> > format to allow for scaling.
>>
>> SVG would be fine, we can always bake it into an image if needed.
>>
>> Thanks
>>
>>        Dirk
>>
>>
>> ------------------------------------------------------------------------------
>> Throughout its 18-year history, RSA Conference consistently attracts the
>> world's best and brightest in the field, creating opportunities for
>> Conference
>> attendees to learn about information security's most important issues
>> through
>> interactions with peers, luminaries and emerging and established
>> companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev
>> _______________________________________________
>> Opensg-users mailing list
>> Opensg-users@...
>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>
>
>

Hi David,

nice work, thanks to all the artists for their efforts!

Here are my $.02:

Group A:

I like the circuit board effect on the top left one, but the graphic leaves a 
lot of the text empty, I would try to stretch it a little further right. I also 
like orange as a base color (just my personal preference ;).

Group B:

I like the 'graph' graphic, and I think the banner looks pretty cool. I'm not 
sure if the small versions can stand on their own, without having the 'Open' 
part in the text. Not sure if what it would look like to fit that in the sphere, 
but I'm a little worried about not having it.

Group C:

I like the clear style of the bottom row, not too excited about the checker 
spheres (seen too many ray tracing demos with them ;).

Group D:

I like the top left one a lot, the combination of the shapes together with the 
text has a nice dynamic. The orange text doesn't hurt, either. ;) The left 
column in general is nice, not too excited about the right one.


David has offered to collect responses and coax a second version out of the 
artists, so please comment on them by Friday.

Thanks for all the work!

	Dirk

On 2010-01-23 01:43, David Kabala wrote:
> Here are some of the Logo/Banner concepts that have been produced.
>
> Mike Rinnan
> <--Group A-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/Mike_open%20sg2.jpg
> <http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/Mike_open%20sg2.jpg>

Top left is nice, looks a bit 3d and hints at complexity. Others too 
flat, IMHO. (This is 3d!)

> Amy Dixon
> Izaak Moody
> <--Group B-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OSG2.jpg
> <http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/OSG2.jpg>

These are my favourite. I like the network, the drop shadow and the 
accuented border here. The softer look of the green boxes in the 
network/banner-style is probably neatest, but the SG should have a 
drop-shadow or something.

Also, we should write OpenSG, not just SG. (Imagining the circle as the 
O won't work due to The Other SceneGraph (tm)...)

  > Amy Dixon
> <--Group C-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OpenSG.jpg
> <http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/OpenSG.jpg>

Chessball on chrome plane is a reversal of the classic hello-world 
raytracer. Perhaps something more inventive.

I like the polish of these though. The lower-right is cool, but the 
transparency of the left hemisphere should be a bit more obvious, perhaps.

> Will Schneller
> <--Group D-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OpenSG_Logos_Version1.jpg
> <http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/OpenSG_Logos_Version1.jpg>

Dark gray and yellow aren't really 2010's style of computing colors...
(We've used them to death at my previous job, I'm utterly sick of that 
color combination... no offense meant.)

The cyan color is nice, albeit a little too intense.

These look a bit too flat also, IMO.

Cheers,
/Marcus

Hello David,

many thanks to you and the artists for sending these!

David Kabala wrote:
> Mike Rinnan
> <--Group A-->

I agree with your comment that these look a bit "windows-like", but I 
like the font used here much better than those used in the others, plus 
it has OpenSG in the usual camel case :)

> Amy Dixon
> Izaak Moody
> <--Group B-->

these are very nice and the tree like structure at the top is certainly 
a good image for a scenegraph (perhaps it should be really a tree 
though, i.e. no diamonds ;) ). One potential problem I see is how well 
these fine details scale to very small sizes - would we need a special 
version with reduced detail here?
As mentioned I'm not too excited about the font, the S seems very thin 
compared to the G - might be because I'm so used to seeing mono fonts in 
the text editor ;)

> Amy Dixon
> <--Group C-->

personally I'm not too excited about the checker board spheres, and the 
last row is a bit too stylized for my taste, perhaps with warmer colours 
or a less harsh contrasts?

> Will Schneller
> <--Group D-->

the left ones are nice and clean and I actually like the colour scheme 
;) - perhaps by connecting the boxes to form a graph (tree) the 
connection to the OpenSG's domain could be strengthened.

as a general remark, personally I'd prefer to have OpenSG in the usual 
camel case if the project name is spelled out in the logo.  It should 
probably be in there to avoid confusion as Marcus already observed.

	Cheers,
		Carsten

Thanks for all of the input, I am going to forward this to the artists now,
and try to get a second revision of the favorites.

On Fri, Jan 22, 2010 at 6:43 PM, David Kabala <djkabala@...> wrote:

> Here are some of the Logo/Banner concepts that have been produced.
>
> Mike Rinnan
> <--Group A-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/Mike_open%20sg2.jpg<http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/Mike_open%20sg2.jpg>
>
> Amy Dixon
> Izaak Moody
> <--Group B-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OSG2.jpg<http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/OSG2.jpg>
>
> Amy Dixon
> <--Group C-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OpenSG.jpg<http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/OpenSG.jpg>
>
> Will Schneller
> <--Group D-->
> http://www.vrac.iastate.edu/~dkabala/OpenSG_logos/OpenSG_Logos_Version1.jpg<http://www.vrac.iastate.edu/%7Edkabala/OpenSG_logos/OpenSG_Logos_Version1.jpg>
>
>
> Please let us know what you think.
>
> Thanks,
> David Kabala
>
>
> On Sun, Jan 17, 2010 at 1:40 AM, Dirk Reiners <dirk.reiners@...:
>
>>
>>        Hi David,
>>
>> On 01/13/2010 10:44 AM, David Kabala wrote:
>> > OpenSG dev team, and OpenSG users,
>> >
>> > In light of the recent discussions on OpenSG 2, some of my artist
>> friends
>> > would like to contribute some ideas for an OpenSG branding logo/icon.
>>  If
>> > some of these icon/logos are acceptable, then we would love to
>> contribute
>> > them.
>>
>> Sounds great. Carsten is right that it's not the most pressing need, but
>> if your
>> artists have the time it would be time well spent.
>>
>> > Would this be welcome/needed/important?
>>
>> I think so. The Beetle is nice, and I like the spirit of it, but it's
>> getting old...
>>
>> > What,if anything, would you like to see for the logo?
>>
>> Honestly I'm pretty open. Given that one of our core distinguishing
>> factors is
>> multi-threading something threaded might be interesting, but other than
>> that I'm
>> flexible.
>>
>> > On the technical side, we are interested in making the logo in the svg
>> > format to allow for scaling.
>>
>> SVG would be fine, we can always bake it into an image if needed.
>>
>> Thanks
>>
>>        Dirk
>>
>>
>> ------------------------------------------------------------------------------
>> Throughout its 18-year history, RSA Conference consistently attracts the
>> world's best and brightest in the field, creating opportunities for
>> Conference
>> attendees to learn about information security's most important issues
>> through
>> interactions with peers, luminaries and emerging and established
>> companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev
>> _______________________________________________
>> Opensg-users mailing list
>> Opensg-users@...
>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>
>
>

Hi,

On Wed, 2010-01-27 at 11:09 +0100, Andreas Halm wrote:
> Hi,
> 
> Some problems began to pop up in December but I didn't have time to get to
> the bottom of it then. The graphics errors are like all kind of errors,
> polygons going to infinity, textures missing, shaders not producing the
> correct result. I disabled using vertex buffer objects for one graphics
> subroutine and it works perfectly again. So I am thinking it looks like it
> has something to do with data not being uploaded to OpenGL objects
> correctly.
> This may happen due to some internal change in OpenSG 2 or it may even be
> related to my change of the operating system (from Vista to Win7), which
> unfortunately happened nearly at the same time.
> 
> 1. Is it ok to mix normal OpenGL objects created using glGenBuffersARB (for
> example) with OpenSG code or is there some other method one should use? Does
> OpenSG need to know of the OpenGL objects I am using?

yes it is fine, OpenSG uses the standard OpenGL functions to allocate
OpenGL functions so there should not be an overlap, except of course
there are some bugs somewhere.

> 2. When should OpenGL objects be initialized? I do that while the scene
> graph is created but it could of course be delayed. Class::
> initMethod(InitPhase ePhase) does kinda look like a good candidate

initialized in the sense that you want to call OpenGL directly ?

::initMethod most likely not as you do not have an active context at 
that time (these are triggered during osgInit). You have to have at
least the Window created and initialized. 

The general infrastructure that serializes access to the context is
centred around the DrawTask structures of the window which allows
applications to submit tasks and takes care that they are executed with
the active context. Either as part of the window->render() call or
in parallel (but the parallel part might not work nicely with the
passive or glut window). But this is currently work in progress and
still a moving target and mainly used internally by the drawer, hence
there aren't much examples or documentation. One example that uses it
is the compute stuff from my addon tree. If you want to try this you
need a current OpenSG version. And if you get stuck ask ;)

 

A general guess as to your problems, what could have happened around
that time frame is that stricter/consistent context rules came into
place (e.g. after window->init() the context is in general not active
any more, always and not dependent on the window you use as before) and
that you do OpenGL calls without having an active context (don't know
about your app setup). The passive window also needed some commits to
sort it out. 

Could you try an OpenGL debugger and see if that might be the case. 

kind regards
  gerrit

Hi,

> A general guess as to your problems, what could have happened around
> that time frame is that stricter/consistent context rules came into
> place (e.g. after window->init() the context is in general not active
> any more, always and not dependent on the window you use as before) and
> that you do OpenGL calls without having an active context (don't know
> about your app setup). The passive window also needed some commits to
> sort it out.

That is exactly what i wanted to say, the display looks like the context is
not active while some of the data is transferred. However, the one display
routine that I fixed by disabling usage of vertex buffer objects actually
does late initialization (upload the vertex data to the buffer) during the
normal "draw" call - in which case the context should definitely be
available ..

I am using WIN32Window though, the version in use is 2163. The svn log does
not show many interesting changes there so I guess no need to search there
for problems.
 
> Could you try an OpenGL debugger and see if that might be the case.

Guess what, I just tried Glintercept and it crashes somewhere (not in my
code). Bad luck.
It logs some GL errors though for wglGetPixelFormat before crashing, at some
point where no window seems to exist. 

Aloha, Andi

Hi,

On Wed, 2010-01-27 at 16:12 +0100, Andreas Halm wrote:
> Hi,
> 
> > A general guess as to your problems, what could have happened around
> > that time frame is that stricter/consistent context rules came into
> > place (e.g. after window->init() the context is in general not active
> > any more, always and not dependent on the window you use as before) and
> > that you do OpenGL calls without having an active context (don't know
> > about your app setup). The passive window also needed some commits to
> > sort it out.
> 
> That is exactly what i wanted to say, the display looks like the context is
> not active while some of the data is transferred. However, the one display
> routine that I fixed by disabling usage of vertex buffer objects actually
> does late initialization (upload the vertex data to the buffer) during the
> normal "draw" call - in which case the context should definitely be
> available ..

hmm during draw it should, could you dump what wglGetCurrentDC() and
wglGetCurrentContext() return at that point ?

Another question you don't shadow OpenSG objects ?, e.g. have an OpenSG
property but upload the data outside OpenSG. I changed some code in
this path (e.g IIRC something did not work as expected) so I might have
enabled something that interferes with what you do. If you can, could
you go back to before version 2153 as this one does the initial vbo code
path changes.

> I am using WIN32Window though, the version in use is 2163. The svn log does
> not show many interesting changes there so I guess no need to search there
> for problems.

you can try to explicitly keep the window active, e.g. by calling 
window->activate(), that should be done after window->init() and 
window->render(). I would call window->deactivate() before calling
into window->render(). Don't know if there are checks inside.

> > Could you try an OpenGL debugger and see if that might be the case.
> 
> Guess what, I just tried Glintercept and it crashes somewhere (not in my
> code). Bad luck.
> It logs some GL errors though for wglGetPixelFormat before crashing, at some
> point where no window seems to exist. 

ok. Could you send me the partial log and if possible the callstack of
the crash (direct is ok).

kind regards
  gerrit

Hi,

> hmm during draw it should, could you dump what wglGetCurrentDC() and
> wglGetCurrentContext() return at that point ?

Looks quite correct.

> Another question you don't shadow OpenSG objects ?, e.g. have an OpenSG
> property but upload the data outside OpenSG. I changed some code in
> this path (e.g IIRC something did not work as expected) so I might have
> enabled something that interferes with what you do. If you can, could
> you go back to before version 2153 as this one does the initial vbo
> code
> path changes.

If I understood correctly then no I don't shadow OpenSG objects. Just to be
absolutely clear, I do all the
glGenBuffersARB, glBindBufferARB, glBufferDataARB and glBufferSubDataARB
stuff myself, but the whole thing is contained in a FC.

> > It logs some GL errors though for wglGetPixelFormat before crashing,
> at some
> > point where no window seems to exist.
> 
> ok. Could you send me the partial log and if possible the callstack of
> the crash (direct is ok).

I threw it away because it looked so absolutely not helpful to me. Of course
I can generate a new one. The callstack was not helpful either, it did not
contain any of my code, but the nvidia driver iirc.

Could this have something to do with multithreading? Is the OpenGL context
in OpenSG accessed from multiple threads?
It must have something to do with Windows 7 though (or the Win7 driver), the
display code did not change in the last 6 month ...

Aloha, Andi

Hi,

On Thu, 2010-01-28 at 11:07 +0100, Andreas Halm wrote:
> Hi,
> 
> > hmm during draw it should, could you dump what wglGetCurrentDC() and
> > wglGetCurrentContext() return at that point ?
> 
> Looks quite correct.

ok.

> > Another question you don't shadow OpenSG objects ?, e.g. have an OpenSG
> > property but upload the data outside OpenSG. I changed some code in
> > this path (e.g IIRC something did not work as expected) so I might have
> > enabled something that interferes with what you do. If you can, could
> > you go back to before version 2153 as this one does the initial vbo
> > code
> > path changes.
> 
> If I understood correctly then no I don't shadow OpenSG objects. Just to be
> absolutely clear, I do all the
> glGenBuffersARB, glBindBufferARB, glBufferDataARB and glBufferSubDataARB
> stuff myself, but the whole thing is contained in a FC.

that's the first half, setting up the data, which element does the
drawing, e.g. use the data ?

> > > It logs some GL errors though for wglGetPixelFormat before crashing,
> > at some
> > > point where no window seems to exist.
> > 
> > ok. Could you send me the partial log and if possible the callstack of
> > the crash (direct is ok).
> 
> I threw it away because it looked so absolutely not helpful to me. Of course
> I can generate a new one. The callstack was not helpful either, it did not
> contain any of my code, but the nvidia driver iirc.

> Could this have something to do with multithreading? Is the OpenGL context
> in OpenSG accessed from multiple threads?

not unless you explicitly enable it in the window (setting
Window::drawMode)

> It must have something to do with Windows 7 though (or the Win7 driver), the
> display code did not change in the last 6 month ...

This unfortunately is still a possibility. I don't have a Window7
machine so I can't really test in this environment. Do you have 
access to an older Windows version (say xp) or is there anyway
somebody else can test it ?

kind regards
  gerrit

Hi,


> > > Another question you don't shadow OpenSG objects ?, e.g. have an
> OpenSG
> > > property but upload the data outside OpenSG. I changed some code in
> > > this path (e.g IIRC something did not work as expected) so I might
> have
> > > enabled something that interferes with what you do. If you can,
> could
> > > you go back to before version 2153 as this one does the initial vbo
> > > code
> > > path changes.
> >
> > If I understood correctly then no I don't shadow OpenSG objects. Just
> to be
> > absolutely clear, I do all the
> > glGenBuffersARB, glBindBufferARB, glBufferDataARB and
> glBufferSubDataARB
> > stuff myself, but the whole thing is contained in a FC.
> 
> that's the first half, setting up the data, which element does the
> drawing, e.g. use the data ?

The same FC object. Nothing fancy ;-)
Also the problem must be the setup, not the drawing, as the errors are not
truly random - once the uploading is finished, the graphic errors always
stay the same and you can look at them in detail :-) Funnily enough, most of
the data gets transferred correctly.

> > It must have something to do with Windows 7 though (or the Win7
> driver), the
> > display code did not change in the last 6 month ...
> 
> This unfortunately is still a possibility. I don't have a Window7
> machine so I can't really test in this environment. Do you have
> access to an older Windows version (say xp) or is there anyway
> somebody else can test it ?

Well what do you know, it does work under XP. However, an internet search on
OpenGL problems on Windows 7 does not turn out anything interesting. So if
anybody has an idea where to look ...

Aloha, Andi

Hi, 

when writing an own Nodecore, I faced similar problems. The solution in my case was to "unbind" the buffer with 
glBindBuffer(GL_ARRAY_BUFFER,0);
after usage. Maybe it helps.

Daniel

-------- Original-Nachricht --------
> Datum: Fri, 29 Jan 2010 16:13:27 +0100
> Von: "Andreas Halm" <andreas.halm@...>
> An: opensg-users@...
> Betreff: Re: [Opensg-users] Graphic Errors

> Hi,
> 
> 
> > > > Another question you don't shadow OpenSG objects ?, e.g. have an
> > OpenSG
> > > > property but upload the data outside OpenSG. I changed some code in
> > > > this path (e.g IIRC something did not work as expected) so I might
> > have
> > > > enabled something that interferes with what you do. If you can,
> > could
> > > > you go back to before version 2153 as this one does the initial vbo
> > > > code
> > > > path changes.
> > >
> > > If I understood correctly then no I don't shadow OpenSG objects. Just
> > to be
> > > absolutely clear, I do all the
> > > glGenBuffersARB, glBindBufferARB, glBufferDataARB and
> > glBufferSubDataARB
> > > stuff myself, but the whole thing is contained in a FC.
> > 
> > that's the first half, setting up the data, which element does the
> > drawing, e.g. use the data ?
> 
> The same FC object. Nothing fancy ;-)
> Also the problem must be the setup, not the drawing, as the errors are not
> truly random - once the uploading is finished, the graphic errors always
> stay the same and you can look at them in detail :-) Funnily enough, most
> of
> the data gets transferred correctly.
> 
> > > It must have something to do with Windows 7 though (or the Win7
> > driver), the
> > > display code did not change in the last 6 month ...
> > 
> > This unfortunately is still a possibility. I don't have a Window7
> > machine so I can't really test in this environment. Do you have
> > access to an older Windows version (say xp) or is there anyway
> > somebody else can test it ?
> 
> Well what do you know, it does work under XP. However, an internet search
> on
> OpenGL problems on Windows 7 does not turn out anything interesting. So if
> anybody has an idea where to look ...
> 
> Aloha, Andi
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Opensg-users mailing list
> Opensg-users@...
> https://lists.sourceforge.net/lists/listinfo/opensg-users

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

On 2010-01-25 11:25, Marcus Lindblom wrote:
> It's an implementation of Bullet's (the physics engine)
> btStridingMeshInterface that allows one to use OSG::Geometry:s as source
> data for collision meshes.

Obviously:

#define ORZ_RUNTIME_ASSERT(e) if(e) throw std::runtime_error(#e);

Should be:

#define ORZ_RUNTIME_ASSERT(e) if(!e) throw std::runtime_error(#e);

But you'll soon discover that. :)

(We're using a more advanced assert implementation that includes, line, 
file, function and a call stack, and is MSVS-specific at the moment.)

Cheers,
/Marcus

Hi Marcus,

On 01/25/2010 04:25 AM, Marcus Lindblom wrote:
> Hi all,
>
> I'd just thought I'd post this here, so that anyone could find it easily
> (until it's added into contrib or wherever suitable).
>
> It's an implementation of Bullet's (the physics engine)
> btStridingMeshInterface that allows one to use OSG::Geometry:s as source
> data for collision meshes.
>
> It places some restrictions on the OSG::Geometry (only triangles and
> triangle strips and only floats) but it works well for VRML-loaded
> meshes so I hope it'll be useful.

that sounds pretty cool! Could we coax you into write a little demo example that 
uses it with Bullet? Something that has a bunch of simple shapes falling and 
bouncing (always a favorite physics demo)? :)

I'd be very happy to add that to the system! Given that none of us have any 
experience with Bullet it would probably take us a lot of time, but given that 
you use it I'd hope it would be pretty simple...

Thanks

	Dirk

On 2010-01-26 07:13, Dirk Reiners wrote:
>
> 	Hi Marcus,
>
> On 01/25/2010 04:25 AM, Marcus Lindblom wrote:
>> Hi all,
>>
>> I'd just thought I'd post this here, so that anyone could find it easily
>> (until it's added into contrib or wherever suitable).
>>
>> It's an implementation of Bullet's (the physics engine)
>> btStridingMeshInterface that allows one to use OSG::Geometry:s as source
>> data for collision meshes.
>>
>> It places some restrictions on the OSG::Geometry (only triangles and
>> triangle strips and only floats) but it works well for VRML-loaded
>> meshes so I hope it'll be useful.
>
> that sounds pretty cool! Could we coax you into write a little demo example that
> uses it with Bullet? Something that has a bunch of simple shapes falling and
> bouncing (always a favorite physics demo)? :)
 >
> I'd be very happy to add that to the system! Given that none of us have any
> experience with Bullet it would probably take us a lot of time, but given that
> you use it I'd hope it would be pretty simple...

We don't have collision response and dynamics in our app, hence no 
experience with that, but I should be able to steal enough of that code 
from some other Bullet example. :)

I'll see what I can come up with. This week(-end) is rather busy though.

Cheers,
/Marcus

On 2010-01-23 22:02, Carsten Neumann wrote:
> Hello all,
>
> while investigating Georg's problem I had to apply the attached patch to
> make the Qt4 code compile (it had problems finding the Qt headers). I
> did not want to apply the patch right away, because I was wondering if
> this is a problem with the way Fedora organizes the Qt headers or the
> configure/make build system?
> If you use 1.8 + Qt4 I'd appreciate if you could let me know where your
> Qt headers are and how you configure/build OpenSG. Or perhaps you have
> something like the attached applied locally?

I'm using 2.0 as you know, but anyway I think the #include-style you've 
swithced to in your patch is perferrable, both for aestethic reasons and 
for the fact that OpenSG&Qt using apps don't need to add a bazillon 
include paths to their config, only the top Qt dir.

The non-.h ending files are also the official way of including QT, IIUC. 
(they mostly forward to a corresponding qfoo.h file, a scheme similar to 
what has been discussed for OpenSG now and then.)

Anyway, you could change #include <Qt/qwidget.h> to #include 
<QtGui/QWidget> as well, etc.

Cheers,
/Marcus

Hi,

On Mon, 2010-01-25 at 10:30 +0800, Gerrit Voß wrote:
> Hi,
> 
> > 
> > Absolutely, in fact I may prefer to work off of it with you, if that
> > is also ok.
> > 
> 
> fine with me, I added you to both trees so you should be able to 
> push to them.
> 

something I forgot. I will tend to rebase the core OpenSG tree as I 
pull changes from the main tree so that the changes for the toolbox
stay on top of the master reference.

Depending on how your setup is and how many people will work of it this
might be a little inconvenient, if so let me know.

I'll try also try to put up more documentation of how this works in
general into the OpenSG Wiki.

kind regards
  gerrit