plib-users

R: [Plib-users] Status of freeglut and the main loop

[Paolo L. <p.l...@ci...>]

SkyFlash wrote:
> Especially cause I have the well known problem that I need to deallocate
> memory when the window exits, and GLUT wont do that cause it calls
> exit(0).

Couldn't you register the deallocation function to the atexit() mechanism?
It isn't just at window close, yet it's sure before exiting.

Re: [Plib-users] Status of freeglut and the main loop

[Steve B. <sjb...@ai...>]

SkyFlash wrote:
> Can I exchange the GLUT libs with the FreeGlut libs and it will all run
> fine, or are there any differences between the two?

There are some minor differences.  Most programs work just fine with either.

> Especially cause I have the well known problem that I need to deallocate
> memory when the window exits, and GLUT wont do that cause it calls
> exit(0).
> 
> Is that already changed in freeglut or do I need to hack it to use PLIB
> with it?

freeglut has a bunch of improvements - as I recall, that's one of them.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-users] Status of freeglut and the main loop

[SkyFlash <sky...@ch...>]

Can I exchange the GLUT libs with the FreeGlut libs and it will all run
fine, or are there any differences between the two?

Especially cause I have the well known problem that I need to deallocate
memory when the window exits, and GLUT wont do that cause it calls
exit(0).

Is that already changed in freeglut or do I need to hack it to use PLIB
with it?

Ralf Pietersz

[Plib-users] compiling in MSVC++

[Clyde A. <nin...@ho...>]

Hi!  I am new to this list, but I was wondering if someone here can help me.

I am trying to compile some code using the PLIB library, but I am unable to 
get the code to link properly.  I can get the code to compile, and I can get 
the sample projects to link, but even when I cut and paste the sample code 
into a new project, I get linker errors aplenty.

The answer to this is obviously that I have a wrong project type selected.  
I am using a Win32 console app for my project type, and that works fine for 
my GLUT projects, but it won't work for PLIB.  Can anyone please tell me how 
to get it to compile in Visual Studio, or how to create a new project type 
in the main list that will work with GLUT and PLIB?

Thanks in advance

Dave Brady



_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

Re: [Plib-users] cull and draw

[Tony J. <ton...@ya...>]

Hi Steve,

Thanks for the quick response.

Does the answer depend on the size of the world ? I was thinking of a =
large world where there might be a lot of detail/models in the next =
valley etc that you might not bother to draw. Or does the overhead for =
occlusion culling scale with world size in such a way as to still make =
it not profitable - and better off looking for another solution ?

Tony Joblin

  ----- Original Message -----=20
  From: Steve Baker=20
  To: pli...@li...=20
  Sent: Monday, February 24, 2003 10:19 AM
  Subject: Re: [Plib-users] cull and draw


  Tony Joblin wrote:

  > Does the cull and draw function do any occlusion culling or does it =
only=20
  > cull to the view frustrum ?

  It only culls to the view frustum.  For outdoor applications, =
occlusion
  culling is more costly than it saves time on - and PLIB has mainly =
been
  used for outdoor-type applications.  It wouldn't be all that hard to =
add
  though.
  ---------------------------- Steve Baker -------------------------
  HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
  HomePage : http://www.sjbaker.org
  Projects : http://plib.sf.net    http://tuxaqfh.sf.net
              http://tuxkart.sf.net http://prettypoly.sf.net
  -----BEGIN GEEK CODE BLOCK-----
  GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- =
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ =
y++++
  -----END GEEK CODE BLOCK-----



  -------------------------------------------------------
  This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
  The most comprehensive and flexible code editor you can use.
  Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
  www.slickedit.com/sourceforge
  _______________________________________________
  plib-users mailing list
  pli...@li...
  https://lists.sourceforge.net/lists/listinfo/plib-users

Re: [Plib-users] cull and draw

[Steve B. <sjb...@ai...>]

Tony Joblin wrote:

> Does the cull and draw function do any occlusion culling or does it only 
> cull to the view frustrum ?

It only culls to the view frustum.  For outdoor applications, occlusion
culling is more costly than it saves time on - and PLIB has mainly been
used for outdoor-type applications.  It wouldn't be all that hard to add
though.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-users] Tiled terrain

[Tony J. <ton...@ya...>]

Hi Everyone,

In the process of learning some OpenGL and Plib, I am writing an app to =
display a terrain from a height map - similar to some of the stuff on =
www.gametutorials.com. In my first cut, I was just using a single NxN =
VtxTable to render the terrain. I am assuming that at some point I will =
get better performance by using a number of VtxTable tiles and letting =
cull and draw remove anything that is not viewable. I was wondering if =
anyone had any experience or rules of thumb as when I should split large =
tiles into smaller ones ?

Tony Joblin

[Plib-users] cull and draw

[Tony J. <ton...@ya...>]

Hi,

Does the cull and draw function do any occlusion culling or does it only =
cull to the view frustrum ?

Tony Joblin

Re: [Plib-users] configure/compile issues...Help?

[Bernie B. <bb...@bi...>]

On Sat, 22 Feb 2003 17:30:32 -0800
Shawn Somers <so...@w-...> wrote:

> 
> >
> > It's not even finding X windows - and without that, it has no chance of
> > finding OpenGL.
> >
> > I suggest you look in the 'config.log' file where you'll see that the
> > configure script has tried to compile a five line C program and link it to
> > X.  For some reason that failed - and we need to know why - you should see
> > the error message towards the end of the file.
> 
> 
> Is this what I'm looking for?
> 
> ##############################config.log#####################
> configure:10523: checking for X
> configure:10624: gcc -E  -I/usr/local/include conftest.c
> cpp0: warning: changing search order for system directory
> "/usr/local/include" cpp0: warning:   as it has already been specified as a
> non-system directory
> configure:10621:27: X11/Intrinsic.h: No such file or directory

Looks like you have to install the development packages.  You don't need them
to run GL programs but you do need them to compile.

Bernie

Re: [Plib-users] configure/compile issues...Help?

[ovrundr <ov...@ya...>]

--- Shawn Somers <so...@w-...> wrote:
> ./configure returns the following error, and As such, I cant
> compile...
> 
> checking for X... no
> checking for glNewList in -lGL... no
> checking for glNewList in -lMesaGL... no
> configure: error: could not find working GL library
> [root@Grindhead plib-1.6.0]#
> 
> I KNOW that I've got a working GL install, as I have many GL based
> games that 
> I play on a regular basis...
> 
> I'm currently using an Nvidia GF2, with their drivers.
> 
> How do I get configure to find the GL libs on My system, and
> compile??
> 
> Shawn
> 

Shawn,

I had the same error and found a post a couple months back
that had a change to the configure.in file that fixed the problem. 

Can't remember what month the posting was in, but it had a subject
that you will recognize.


=====




__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: [Plib-users] configure/compile issues...Help?

[Shawn S. <so...@w-...>]

>
> It's not even finding X windows - and without that, it has no chance of
> finding OpenGL.
>
> I suggest you look in the 'config.log' file where you'll see that the
> configure script has tried to compile a five line C program and link it=
 to
> X.  For some reason that failed - and we need to know why - you should =
see
> the error message towards the end of the file.


Is this what I'm looking for?

##############################config.log#####################
configure:10523: checking for X
configure:10624: gcc -E  -I/usr/local/include conftest.c
cpp0: warning: changing search order for system directory "/usr/local/inc=
lude"
cpp0: warning:   as it has already been specified as a non-system directo=
ry
configure:10621:27: X11/Intrinsic.h: No such file or directory
configure:10630: $? =3D 1
configure: failed program was:
#line 10620 "configure"
#include "confdefs.h"
#include <X11/Intrinsic.h>
configure:10675: gcc -o conftest -g -O2 -I/usr/local/include =20
-I/usr/local/include  -L/usr/local/lib conftest.c -lXt  >&5
cc1: warning: changing search order for system directory "/usr/local/incl=
ude"
cc1: warning:   as it has already been specified as a non-system director=
y
configure:10664:27: X11/Intrinsic.h: No such file or directory
configure:10678: $? =3D 1
configure: failed program was:
#line 10663 "configure"
#include "confdefs.h"
#include <X11/Intrinsic.h>
int
main ()
{
XtMalloc (0)
  ;
  return 0;
}
configure:10722: result: no

Re: [Plib-users] configure/compile issues...Help?

[Steve B. <sjb...@ai...>]

Shawn Somers wrote:
> ./configure returns the following error, and As such, I cant compile...
> 
> checking for X... no
> checking for glNewList in -lGL... no
> checking for glNewList in -lMesaGL... no
> configure: error: could not find working GL library
> [root@Grindhead plib-1.6.0]#

It's not even finding X windows - and without that, it has no chance of
finding OpenGL.

I suggest you look in the 'config.log' file where you'll see that the configure
script has tried to compile a five line C program and link it to X.  For some
reason that failed - and we need to know why - you should see the error message
towards the end of the file.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-users] configure/compile issues...Help?

[Shawn S. <so...@w-...>]

=2E/configure returns the following error, and As such, I cant compile...

checking for X... no
checking for glNewList in -lGL... no
checking for glNewList in -lMesaGL... no
configure: error: could not find working GL library
[root@Grindhead plib-1.6.0]#

I KNOW that I've got a working GL install, as I have many GL based games =
that=20
I play on a regular basis...

I'm currently using an Nvidia GF2, with their drivers.

How do I get configure to find the GL libs on My system, and compile??

Shawn

Re: [Plib-users] i810_audio with oss?

[ovrundr <ov...@ya...>]

--- Chris Jewell <vs0...@li...> wrote:

> I have an SIS7012 soundcard in my machine running RedHat 8.0 that
> uses the 
> i810_audio driver together with the AC97_codec module.  I am trying
> to get 
> sound in FlightGear 

> 
> Many thanks,
> 
> Chris Jewell

I have a Realtek ALC650 with a AC'97 chipset that uses 
the same drivers.

I've done a little debug and found the following:

in slDSP::open

stereo = ioctl ( SOUND_PCM_WRITE_CHANNELS, _stereo ? 2 : 1 ) >= 2 ;
bps    = ioctl ( SOUND_PCM_WRITE_BITS, _bps ) ;

input values:
SOUND_PCM_WRITE_CHANNELS = -1073459194
SOUND_PCM_WRITE_BITS = -1073459195
_stereo = 1
_bps = 8

return value from stereo = 2
return value from bps = 16

Which leads to:
if ( getBps() != 8 )
slScheduler: Needs a sound card that supports 8 bits per sample.
and
if ( getStereo())
slScheduler: Needs a sound card that supports monophonic replay.

Don't know if this driver will not handle 8 bit mono 
or maybe the ioctl call is using wrong values.

Does anyone know the answer or where I can go next to debug futher?

Rick






=====




__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: [Plib-users] i810_audio with oss?

[David G. <xh...@ma...>]

On Fri, 2003-02-21 at 18:44, Iaian wrote:
> I ended up purchasing a sound blaster
> live card and all my sound problems went away.

I had the exact same problem (I'm also running RH 8!) and just ended up
purchasing a SoundBlaster Live! card.  They're quite cheap - I got mine
for $23 on the internet.

-David Giraud

Re: [Plib-users] i810_audio with oss?

[Iaian <ia...@sh...>]

On Fri, Feb 21, 2003 at 10:13:28PM +0000, Chris Jewell wrote:
> Hi,
> 
> I have an SIS7012 soundcard in my machine running RedHat 8.0 that uses the 
> i810_audio driver together with the AC97_codec module.

I had similar plib problems with this audio chip on my ECS K7S5A
motherboard. I tried different drivers (included with the linux
kernel, OSS/Linux, and ALSA) but could not get the sound in FlightGear
to work properly. I've be told that linux drivers for some
on-board chips are quite limited. I suspect this limitation also
exists with soundcards using the SiS7012 chip so you might be stuck
with the commercial OSS version. I ended up purchasing a sound blaster
live card and all my sound problems went away.

IB

[Plib-users] i810_audio with oss?

[Chris J. <vs0...@li...>]

Hi,

I have an SIS7012 soundcard in my machine running RedHat 8.0 that uses th=
e=20
i810_audio driver together with the AC97_codec module.  I am trying to ge=
t=20
sound in FlightGear and have managed it only by downloading the commercia=
l=20
evaluation version of OSS from 4Front.  Being a student budget sort of a=20
person I don't really want to pay for the unlimited version of OSS.  Howe=
ver,=20
I thought that OSS was distributed with the linux kernel?  I have found t=
he=20
sound.o module in my kernel modules directory but cannot get it working. =
 I=20
changed the line "alias sound-slot0 i810_audio" to "alias sound-slot0 sou=
nd"=20
which seems to load the sound.o modules but the sound still does not work=
=2E

Can anyone give me instructions on how (if at all) I can get this working=
?

Many thanks,

Chris Jewell

Re: [Plib-users] How to run loader and render in separate threads?

[Brian R H. <bh...@cs...>]

>> My fundamental objective is to be able to use the time waiting for
>> the glutSwapBuffers command to return.  I can limit the use of this
>> time to non-OpenGL and non-scene graph processing.

> I guess I don't know enough at this low level to say if this time
> slice is usable or not.  Steve or others could probably say something
> more informative.  My gut feeling is that on modern hardware, the
> graphics card would typically return control back to the app pretty
> quickly.

My experience is that in a single threaded application the time lost
waiting for the next vertical refresh is huge.

It would be nice to be able to load new models in another thread but I'm
not willing to write my own loader so I'll live with limiting using
ssgLoadXXX functions to the rendering thread... too bad because I want to
load objects during run time without dropping my frame rate too much.

Brian

Re: [Plib-users] How to run loader and render in separate threads?

[Curtis L. O. <cu...@fl...>]

Brian R Hill writes:
> Thanks for the info. I'm going to browse through the flight gear code to
> get a better idea about what I'm up against.
> 
> A quick (maybe) question about building sub trees in a separate thread. Do
> you use the ssgLoadXXX functions?

No, we never use ssgLoadXXX functions outside the main render thread.
The reason is that the user could conceivable use any model they
want.  Most likely it would include textures, and thus this would
trigger the execution of opengl commands in the 2nd thread.

If you could guarantee for ever and for always that your models would
never have a texture'd component, then you could probably get away
with using ssgLoadXXX() routines in a 2nd thread.

We get away with paging terrain in a 2nd thread because:

  - we preload all the possible terrain textures

  - we have our own terrain format/loader so we have complete control
    over what the loader does.

  - If we encounter any externally referenced models attached to a
    terrain chunk, we shove those on the end of a queue for the main
    render thread to load.

  - The final scene graph subtree created by the paging thread is
    shoved onto a queue and connected into the main scene graph by the
    main render thread.

> My review of the loader code indicated it issues OpenGL commands
> which should be either a no-no or do I just have make sure the
> rendering thread isn't active at the time (in ssgCullAndDraw or
> drawing overlays or glutSwapBuffers)?

You would need to ensure that you are outside of your main render loop
using some sort of locks.  However, in that case, you end up not
gaining much (if anything) with threading vs. doing everything in a
single thread .

> My fundamental objective is to be able to use the time waiting for
> the glutSwapBuffers command to return.  I can limit the use of this
> time to non-OpenGL and non-scene graph processing.

I guess I don't know enough at this low level to say if this time
slice is usable or not.  Steve or others could probably say something
more informative.  My gut feeling is that on modern hardware, the
graphics card would typically return control back to the app pretty
quickly.

Our motivation for doing threaded tile paging was to minimize pauses
and jitters when a fresh set of tiles needed to be paged in.

Regards,

Curt.
-- 
Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-users] How to run loader and render in separate threads?

[Steve B. <sjb...@ai...>]

Brian R Hill wrote:
> Does anyone have an example of how to run a loader process (read files,
> create ssg objects, merge into scene graph) and rendering process (glut and
> ssgcullandraw) in separate threads?

That's not very do-able - SSG was never designed to work that way.

I believe FlightGear has done something like that - but not in a
totally general way.

I would recommend assembling a complete sub-graph in the parallel
thread and only connecting it into the main scene graph in the main
rendering thread.  However, SSG objects are not thread-safe so you
have to be spectacularly careful not to access things in one thread
that are in use in the other.

There are other libraries that went overboard to get all this perfect - but
they weren't written in a weekend like the first version of SSG and they
tend to impose other nasty limitations on your code.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

Re: [Plib-users] How to run loader and render in separate threads?

[Brian R H. <bh...@cs...>]

Curt,

Thanks for the info. I'm going to browse through the flight gear code to
get a better idea about what I'm up against.

A quick (maybe) question about building sub trees in a separate thread. Do
you use the ssgLoadXXX functions?
My review of the loader code indicated it issues OpenGL commands which
should be either a no-no or do I just have
make sure the rendering thread isn't active at the time (in ssgCullAndDraw
or drawing overlays or glutSwapBuffers)?

My fundamental objective is to be able to use the time waiting for the
glutSwapBuffers command to return.
I can limit the use of this time to non-OpenGL and non-scene graph
processing.

Brian



                                                                                                                                  
                      "Curtis L.                                                                                                  
                      Olson" <curt             To:      pli...@li...                                          
                      @flightgear.org>         cc:                                                                                
                      Sent by:                 Subject: Re: [Plib-users] How to run loader and render in separate threads?        
                      plib-users-admin                                                                                            
                                                                                                                                  
                                                                                                                                  
                      02/20/2003 02:01                                                                                            
                      PM                                                                                                          
                      Please respond                                                                                              
                      to plib-users                                                                                               
                                                                                                                                  
                                                                                                                                  




Brian R Hill writes:
> Does anyone have an example of how to run a loader process (read files,
> create ssg objects, merge into scene graph) and rendering process (glut
and
> ssgcullandraw) in separate threads?

FlightGear does this, but I wouldn't call the code straight forward.
There are a couple things you need to watch out for.

You mustn't *ever* interleave opengl commands between two threads.
This is a recipe for disaster.  OpenGL is not thread safe, you can
think of it as a single resource.  Even worse, it's a state machine so
the order of opengl calls is very important.

Imagine if you are rendering in one thread, and loading a model (and
therefore probably textures) in another; and the opengl commands from
those two threads get interleaved.  Most likely you'll just get a
crash, but if your code somehow survived, you'd still likely get some
bizarre rendering effects.

FlightGear goes to great lengths (and thus complexity) to avoid doing
any opengl commands outside of the main render loop.

We also are careful not to alter the main scene graph while it is
being rendered.

So, we:

  - load all self contained models from the main render loop.
    (Terrain is a specialized case that we have complete control over
    so we can load that in the thread.)

  - In the second thread we don't actually modify the main scene
    graph.  Instead we build up sub trees, push those onto a queue,
    and then have the main thread connect this tree into the main
    scene graph.

  - Likewise, we can lop off a sub tree we want to delete in the main
    thread, and then work on deleting it in a 2nd thread ... however
    if you have multiple instances of objects in your graph you need
    to be really careful.  We ended up not doing this in our 2nd
    thread.  Instead we wrote a routine that deletes "n" elements of a
    subtree and then bails out.  This way we can spread the work of
    deleting a sub tree over several frames, call the routine from the
    main render thread, and not worry about scene graph consistency
    issues.

As you can imagine this all adds a big measure of complexity.  We have
load queues, model load queues, attache queues, free queues, etc.  We
have also found that introducing threading is a great way to add
really subtle and very hard to find bugs to your program.

My advice is to only do threading as a last resort.  It's one thing to
code a simple producer / consumer example for a class, it can be an
entirely different thing to add threading to a large, complex, real
world app.  Beware! :-)

Regards,

Curt.
--
Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
plib-users mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-users

Re: [Plib-users] How to run loader and render in separate threads?

[Curtis L. O. <cu...@fl...>]

Brian R Hill writes:
> Does anyone have an example of how to run a loader process (read files,
> create ssg objects, merge into scene graph) and rendering process (glut and
> ssgcullandraw) in separate threads?

FlightGear does this, but I wouldn't call the code straight forward.
There are a couple things you need to watch out for.

You mustn't *ever* interleave opengl commands between two threads.
This is a recipe for disaster.  OpenGL is not thread safe, you can
think of it as a single resource.  Even worse, it's a state machine so
the order of opengl calls is very important.

Imagine if you are rendering in one thread, and loading a model (and
therefore probably textures) in another; and the opengl commands from
those two threads get interleaved.  Most likely you'll just get a
crash, but if your code somehow survived, you'd still likely get some
bizarre rendering effects.

FlightGear goes to great lengths (and thus complexity) to avoid doing
any opengl commands outside of the main render loop.  

We also are careful not to alter the main scene graph while it is
being rendered.

So, we:

  - load all self contained models from the main render loop.
    (Terrain is a specialized case that we have complete control over
    so we can load that in the thread.)

  - In the second thread we don't actually modify the main scene
    graph.  Instead we build up sub trees, push those onto a queue,
    and then have the main thread connect this tree into the main
    scene graph.

  - Likewise, we can lop off a sub tree we want to delete in the main
    thread, and then work on deleting it in a 2nd thread ... however
    if you have multiple instances of objects in your graph you need
    to be really careful.  We ended up not doing this in our 2nd
    thread.  Instead we wrote a routine that deletes "n" elements of a
    subtree and then bails out.  This way we can spread the work of
    deleting a sub tree over several frames, call the routine from the
    main render thread, and not worry about scene graph consistency
    issues.

As you can imagine this all adds a big measure of complexity.  We have
load queues, model load queues, attache queues, free queues, etc.  We
have also found that introducing threading is a great way to add
really subtle and very hard to find bugs to your program.

My advice is to only do threading as a last resort.  It's one thing to
code a simple producer / consumer example for a class, it can be an
entirely different thing to add threading to a large, complex, real
world app.  Beware! :-)

Regards,

Curt.
-- 
Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

[Plib-users] How to run loader and render in separate threads?

[Brian R H. <bh...@cs...>]

Does anyone have an example of how to run a loader process (read files,
create ssg objects, merge into scene graph) and rendering process (glut and
ssgcullandraw) in separate threads?

Thanks,

Brian

R: [Plib-users] Overriding face culling

[Paolo L. <p.l...@ci...>]

Norman,

thanks for the hint - so under your guidelines my implementation is now:

	dontcullface = !dontcullface;
	if ( dontcullface ) {
		glDisable( GL_CULL_FACE );
		ssgOverrideCullface( TRUE );
	}
	else {
		glEnable( GL_CULL_FACE );
		ssgOverrideCullface( FALSE );
	}

Unfortunately it still doesn't work.

Paolo


> -----Messaggio originale-----
> Da: pli...@li...
> [mailto:pli...@li...]Per conto di Norman Vine
> Inviato: mercoledì 19 febbraio 2003 17.02
> A: pli...@li...
> Oggetto: RE: [Plib-users] Overriding face culling
>
>
> Paolo Leoncini writes:
> >
> > Can anybody explain why? and how to force disabling back face culling?
>
>
> Maybe this code snippet will help
>
>
>   /*
>     Multipass rendering sometimes required:
>
>     * Wire plus filled
>     * Filled-front-faces with wire backfaces.
>     * Selected polygons have white wire faces.
>   */
>
>   if ( rendermode & RENDER_TEXTURE )
>   {
>     glEnable ( GL_TEXTURE_2D ) ;
>     ssgOverrideTexture ( FALSE ) ;
>   }
>   else
>   {
>     glDisable ( GL_TEXTURE_2D ) ;
>     ssgOverrideTexture ( TRUE ) ;
>   }
>
>   /*
>     If filled AND not wire AND not backfaces - then need wire
>     as a first pass.
>   */
>
>   if ( (rendermode & RENDER_FILLED    )!=0 &&
>        (rendermode & RENDER_WIRE      )==0 &&
>        (rendermode & RENDER_BACKFACES )==0 )
>   {
>     /* First pass: Both faces, wireframe */
>
>     glPolygonMode ( GL_FRONT_AND_BACK, GL_LINE ) ;
>     glDisable ( GL_CULL_FACE ) ;
>     ssgOverrideCullface ( TRUE ) ;
>     ssgCullAndDraw ( getSceneRoot() ) ;
>
>     /* Zap the Z buffer */
>
>     glClear ( GL_DEPTH_BUFFER_BIT ) ;
>
>     /* Second pass: Front faces only - filled */
>
>     glPolygonMode ( GL_FRONT_AND_BACK, GL_FILL ) ;
>     glEnable ( GL_CULL_FACE ) ;
>     ssgOverrideCullface ( FALSE ) ;
>     ssgCullAndDraw ( getSceneRoot() ) ;
>   }
>   else
>
>   /*
>     If filled AND wire - then need wire as a second
>     pass.
>   */
>
>     if ( (rendermode & RENDER_FILLED)!=0 &&
>        (rendermode & RENDER_WIRE  )!=0 )
>     {
>       setOffsetProjectionMatrix ( PUSH_BACK ) ;
>       glPolygonMode ( GL_FRONT_AND_BACK, GL_FILL ) ;
>       glDisable ( GL_CULL_FACE ) ;
>       ssgOverrideCullface ( TRUE ) ;
>       ssgCullAndDraw ( getSceneRoot() ) ;
>
>       glPolygonMode ( GL_FRONT_AND_BACK, GL_LINE ) ;
>       glEnable ( GL_CULL_FACE ) ;
>       ssgOverrideCullface ( FALSE ) ;
>       ssgCullAndDraw ( getSceneRoot() ) ;
>     }
>     else
>
>     /* We only need one pass.  */
>
>     {
>       if ( rendermode & RENDER_WIRE )
>         glPolygonMode ( GL_FRONT_AND_BACK, GL_LINE ) ;
>       else
>         glPolygonMode ( GL_FRONT_AND_BACK, GL_FILL ) ;
>
>       if ( rendermode & RENDER_BACKFACES )
>       {
>         glDisable ( GL_CULL_FACE ) ;
>         ssgOverrideCullface ( TRUE ) ;
>       }
>       else
>       {
>         glEnable ( GL_CULL_FACE ) ;
>         ssgOverrideCullface ( FALSE ) ;
>       }
>
>       ssgCullAndDraw ( getSceneRoot() ) ;
>     }
>
>   glFinish () ;
>
>
> Ciao
>
> Norman
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users

RE: [Plib-users] Overriding face culling

[Norman V. <nh...@ca...>]

Paolo Leoncini writes:
> 
> Can anybody explain why? and how to force disabling back face culling?


Maybe this code snippet will help


  /*
    Multipass rendering sometimes required:

    * Wire plus filled
    * Filled-front-faces with wire backfaces.
    * Selected polygons have white wire faces.
  */

  if ( rendermode & RENDER_TEXTURE )
  {
    glEnable ( GL_TEXTURE_2D ) ;
    ssgOverrideTexture ( FALSE ) ;
  }
  else
  {
    glDisable ( GL_TEXTURE_2D ) ;
    ssgOverrideTexture ( TRUE ) ;
  }

  /*
    If filled AND not wire AND not backfaces - then need wire
    as a first pass.
  */

  if ( (rendermode & RENDER_FILLED    )!=0 &&
       (rendermode & RENDER_WIRE      )==0 &&
       (rendermode & RENDER_BACKFACES )==0 )
  {
    /* First pass: Both faces, wireframe */

    glPolygonMode ( GL_FRONT_AND_BACK, GL_LINE ) ;
    glDisable ( GL_CULL_FACE ) ;
    ssgOverrideCullface ( TRUE ) ;
    ssgCullAndDraw ( getSceneRoot() ) ;

    /* Zap the Z buffer */

    glClear ( GL_DEPTH_BUFFER_BIT ) ;

    /* Second pass: Front faces only - filled */

    glPolygonMode ( GL_FRONT_AND_BACK, GL_FILL ) ;
    glEnable ( GL_CULL_FACE ) ;
    ssgOverrideCullface ( FALSE ) ;
    ssgCullAndDraw ( getSceneRoot() ) ;
  }
  else

  /*
    If filled AND wire - then need wire as a second
    pass.
  */

    if ( (rendermode & RENDER_FILLED)!=0 &&
       (rendermode & RENDER_WIRE  )!=0 )
    {
      setOffsetProjectionMatrix ( PUSH_BACK ) ;
      glPolygonMode ( GL_FRONT_AND_BACK, GL_FILL ) ;
      glDisable ( GL_CULL_FACE ) ;
      ssgOverrideCullface ( TRUE ) ;
      ssgCullAndDraw ( getSceneRoot() ) ;

      glPolygonMode ( GL_FRONT_AND_BACK, GL_LINE ) ;
      glEnable ( GL_CULL_FACE ) ;
      ssgOverrideCullface ( FALSE ) ;
      ssgCullAndDraw ( getSceneRoot() ) ;
    }
    else

    /* We only need one pass.  */

    {
      if ( rendermode & RENDER_WIRE )
        glPolygonMode ( GL_FRONT_AND_BACK, GL_LINE ) ;
      else 
        glPolygonMode ( GL_FRONT_AND_BACK, GL_FILL ) ;

      if ( rendermode & RENDER_BACKFACES )
      {
        glDisable ( GL_CULL_FACE ) ;
        ssgOverrideCullface ( TRUE ) ;
      }
      else
      {
        glEnable ( GL_CULL_FACE ) ;
        ssgOverrideCullface ( FALSE ) ;
      }

      ssgCullAndDraw ( getSceneRoot() ) ;
    }

  glFinish () ;


Ciao

Norman