plib-devel

RE: [Plib-devel] Nested LOD selectors almost works...

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

Mark K writes:
>
>Nope.  FGFS doesn't nest LOD selectors.

Agreed -- but it does PLib's range selector mechanism and
the code I pointed to shows how to set them up for the current 
EYE Matrix,  albeit for a much more simplistic purpose.

:)

>
>> > HI Mark
>> > 
>> > You could look in the FGFS source to see how it is done there. 
>> > 
>> > Scenery / tilemgr.cxx
>> > // Prepare the ssg nodes ... for each tile, set it's proper
>> > // transform and update it's range selector based on current
>> > // visibilty
>> > void FGTileMgr::prep_ssg_nodes( void )
>> > 
>> > Norman
>> > 

RE: [Plib-devel] Nested LOD selectors almost works...

[Vallevand, M. K <Mar...@UN...>]

That's it!

Yes, all of my tiles share the same origin.

A simple tree looks like this:
root
 |-LOD Selector
    |-branch
    |  |-LOD Selector
    |  |  |-branch
    |  |  |  |-1x1 tile at (0,0)
    |  |  |  |-1x1 tile at (0,1)
    |  |  |  |-1x1 tile at (1,0)
    |  |  |  |-1x1 tile at (1,1)
    |  |  |
    |  |  |-2x2 tile at (0,0)
    |  |
    |  |-LOD Selector
    |  |  |-branch
    |  |  |  |-1x1 tile at (0,2)
    |  |  |  |-1x1 tile at (0,3)
    |  |  |  |-1x1 tile at (1,2)
    |  |  |  |-1x1 tile at (1,3)
    |  |  |
    |  |  |-2x2 tile at (0,2)
    |  |
    |  |-LOD Selector
    |  |  |-branch
    |  |  |  |-1x1 tile at (2,0)
    |  |  |  |-1x1 tile at (2,1)
    |  |  |  |-1x1 tile at (3,0)
    |  |  |  |-1x1 tile at (3,1)
    |  |  |
    |  |  |-2x2 tile at (2,0)
    |  |
    |  |-LOD Selector
    |     |-branch
    |     |  |-1x1 tile at (2,2)
    |     |  |-1x1 tile at (2,3)
    |     |  |-1x1 tile at (3,2)
    |     |  |-1x1 tile at (3,3)
    |     |
    |     |-2x2 tile at (2,2)
    |
    |-4x4 tile at (0,0)

However, the bounding sphere for each tile is in the
correct location.

The solution is what?  Insert a transform branch above the
LOD Selector?  A transform branch in place of the regular
branch?

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho


> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> Sent: Friday, April 28, 2000 1:37 PM
> To: pli...@li...
> Subject: Re: [Plib-devel] Nested LOD selectors almost works...
> 
> 
> "Vallevand, Mark K" wrote:
> > 
> > Nested LOD selectors almost works.
> > 
> > In my program, I recursively partition a tile into sub-tiles at
> > at higher level of detail.  If a tile can be partitioned, I create
> > a LOD selector with 2 kids - one for the lower level of detail
> > tile and a second one that is a branch containing the higher
> > level of detail sub-tiles.  Every thing works together really
> > nice.  The tree seems to be correct, all the leaf nodes at all
> > levels of details are correct, and their bounding spheres
> > have the correct center and radius.  Lots of brute force
> > debugging and print statements makes me believe things
> > are correct.
> > 
> > But, the same debugging and print statements show me
> > that the range calculated in the cull of each LOD selector
> > is the same for each selector.  As I move the camera
> > around the terrain, the range changes and I get different
> > culling, but it is funny because the range calculated seems
> > to be wrong.
> 
> Hmmm - the LOD range is measured to the local origin of the
> model...so could it be that your terrain tiles all share
> a common origin?
> 
> > So, my questions...
> > How is the range calculated when culling to the viewing fustrum?
> 
> I don't calculate the range.  I transform the bounding sphere
> center using the current modelview matrix and compare it to the
> plane equations of the six clipping planes that make up the
> view frustum.
> 
> -- 
> Steve Baker                  http://web2.airmail.net/sjbaker1
> sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
> sj...@ht...      (work)
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] Nested LOD selectors almost works...

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

"Vallevand, Mark K" wrote:
> 
> Nested LOD selectors almost works.
> 
> In my program, I recursively partition a tile into sub-tiles at
> at higher level of detail.  If a tile can be partitioned, I create
> a LOD selector with 2 kids - one for the lower level of detail
> tile and a second one that is a branch containing the higher
> level of detail sub-tiles.  Every thing works together really
> nice.  The tree seems to be correct, all the leaf nodes at all
> levels of details are correct, and their bounding spheres
> have the correct center and radius.  Lots of brute force
> debugging and print statements makes me believe things
> are correct.
> 
> But, the same debugging and print statements show me
> that the range calculated in the cull of each LOD selector
> is the same for each selector.  As I move the camera
> around the terrain, the range changes and I get different
> culling, but it is funny because the range calculated seems
> to be wrong.

Hmmm - the LOD range is measured to the local origin of the
model...so could it be that your terrain tiles all share
a common origin?

> So, my questions...
> How is the range calculated when culling to the viewing fustrum?

I don't calculate the range.  I transform the bounding sphere
center using the current modelview matrix and compare it to the
plane equations of the six clipping planes that make up the
view frustum.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

RE: [Plib-devel] Nested LOD selectors almost works...

[Vallevand, M. K <Mar...@UN...>]

Nope.  FGFS doesn't nest LOD selectors.

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho


> -----Original Message-----
> From: Vallevand, Mark K 
> Sent: Friday, April 28, 2000 12:38 PM
> To: 'pli...@li...'
> Subject: RE: [Plib-devel] Nested LOD selectors almost works...
> 
> 
> A good suggestion.  A cursory look at the code tells
> me that it does things similar to what I want.  And,
> it works.  I'm printing the code for a good look.
> 
> Regards.
> Mark K Vallevand   ma...@rs...
> Outside of a dog, a book is man's best friend.
>  Inside of a dog, its too dark to read.  - Groucho
> 
> 
> > -----Original Message-----
> > From: Norman Vine [mailto:nh...@ca...]
> > Sent: Friday, April 28, 2000 9:38 AM
> > To: pli...@li...
> > Subject: RE: [Plib-devel] Nested LOD selectors almost works...
> > 
> > 
> > Mark K Vallevand writes:
> > >
> > >Nested LOD selectors almost works.
> > >
> > >What could I be doing wrong?
> > >What should I look at to get more info?
> > >
> > 
> > HI Mark
> > 
> > You could look in the FGFS source to see how it is done there. 
> > 
> > Scenery / tilemgr.cxx
> > // Prepare the ssg nodes ... for each tile, set it's proper
> > // transform and update it's range selector based on current
> > // visibilty
> > void FGTileMgr::prep_ssg_nodes( void )
> > 
> > Norman
> > 
> > _______________________________________________
> > plib-devel mailing list
> > pli...@li...
> > http://lists.sourceforge.net/mailman/listinfo/plib-devel
> > 
> 

Re: [Plib-devel] GL_COLOR_MATERIAL pitfall

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

Wolfram Kuss wrote:
> 
> BTW, regarding the GL_COLOUR_MATERIAL problem:
> Steve said some time ago that the next thing to do would be to write
> a program that has the same problem as PLIB/PPE, but is as simple as
> possible.
> 
> I think I read a long time ago about people "logging" OpenGL
> calls with some tool and think the easiest way would be to log
> them and throw out everything unneeded.

Since you mention it...I have been writing exactly such a thing
over the past couple of days.  I have written a header file
containing about a gazillion things like:

#ifdef OPENGL_DEBUG
#define glBegin debug_glBegin
extern void debug_glBegin ( GLenum type ) ;
#endif

...then an executable containing:

void debug_glBegin ( GLenum type )
{
  if ( logging ( "glBegin" ) )
    fprintf ( debug_stderr, "glBegin ( %s ) ;\n".
              enum_to_string ( type ) ) ;

  if ( executing ( "glBegin" ) )
    glBegin ( type ) ;
}

...the result (when it works) will be that you can compile your
opengl program with all your files #including the debugging
header file...then link to the executable and turn debug tracing
on and off either under program control or with a 'signal' from
outside.

That should precisely enable me to do what you say.

> However, I neither found a "generic OpenGL command recorder"
> nor a "Windows-dll-function-call-logger".Does anyone know of such a
> beast?

There are some around - but none that are portable (that I know of).

I've used 'ogldebug' on Silicon Graphics machine, under Linux, you
have a way to compile Mesa to make it trace execution.

But mine will be more flexible and let you do things like telling
the library to record everything from the next swapbuffers to the
one after that to get an entire frame's worth of data.
 
> If not, I could rename opengl.dll and write a new dll, that simply
> calls the old one and logs all calls.

Yep - that would prevent you from having to mess around with header
files - but forces you to trace calls made by other libraries like
GLU...I can see uses for both approaches.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

RE: [Plib-devel] Nested LOD selectors almost works...

[Vallevand, M. K <Mar...@UN...>]

A good suggestion.  A cursory look at the code tells
me that it does things similar to what I want.  And,
it works.  I'm printing the code for a good look.

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho


> -----Original Message-----
> From: Norman Vine [mailto:nh...@ca...]
> Sent: Friday, April 28, 2000 9:38 AM
> To: pli...@li...
> Subject: RE: [Plib-devel] Nested LOD selectors almost works...
> 
> 
> Mark K Vallevand writes:
> >
> >Nested LOD selectors almost works.
> >
> >What could I be doing wrong?
> >What should I look at to get more info?
> >
> 
> HI Mark
> 
> You could look in the FGFS source to see how it is done there. 
> 
> Scenery / tilemgr.cxx
> // Prepare the ssg nodes ... for each tile, set it's proper
> // transform and update it's range selector based on current
> // visibilty
> void FGTileMgr::prep_ssg_nodes( void )
> 
> Norman
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] GL_COLOR_MATERIAL pitfall

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

Wolfram Kuss writes:
> BTW, regarding the GL_COLOUR_MATERIAL problem:
> Steve said some time ago that the next thing to do would be to write
> a program that has the same problem as PLIB/PPE, but is as simple as
> possible.
> 
> I think I read a long time ago about people "logging" OpenGL 
> calls with some tool and think the easiest way would be to log 
> them and throw out everything unneeded.
> 
> However, I neither found a "generic OpenGL command recorder"
> nor a "Windows-dll-function-call-logger".Does anyone know of such a
> beast?
> 
> If not, I could rename opengl.dll and write a new dll, that simply
> calls the old one and logs all calls.

A while back Steve sent me something he had whipped up which he called
"xgl".  Basically you include xgl.h instead of gl.h and prepend an "x"
in front of all your opengl calls.  He then had things structured with
#defines so these could be translated straight to the real opengl
calls, or you could dump a log of the calls to console or file.

A modified version of this is part of the SimGear package:

    ftp://ftp.flightgear.org/pub/fgfs/Source/

Regards,

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

BTW, regarding the GL_COLOUR_MATERIAL problem:
Steve said some time ago that the next thing to do would be to write
a program that has the same problem as PLIB/PPE, but is as simple as
possible.

I think I read a long time ago about people "logging" OpenGL 
calls with some tool and think the easiest way would be to log 
them and throw out everything unneeded.

However, I neither found a "generic OpenGL command recorder"
nor a "Windows-dll-function-call-logger".Does anyone know of such a
beast?

If not, I could rename opengl.dll and write a new dll, that simply
calls the old one and logs all calls.

Bye bye,
Wolfram.

RE: [Plib-devel] Nested LOD selectors almost works...

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

Mark K Vallevand writes:
>
>Nested LOD selectors almost works.
>
>What could I be doing wrong?
>What should I look at to get more info?
>

HI Mark

You could look in the FGFS source to see how it is done there. 

Scenery / tilemgr.cxx
// Prepare the ssg nodes ... for each tile, set it's proper
// transform and update it's range selector based on current
// visibilty
void FGTileMgr::prep_ssg_nodes( void )

Norman

[Plib-devel] Nested LOD selectors almost works...

[Vallevand, M. K <Mar...@UN...>]

Nested LOD selectors almost works.

In my program, I recursively partition a tile into sub-tiles at
at higher level of detail.  If a tile can be partitioned, I create
a LOD selector with 2 kids - one for the lower level of detail
tile and a second one that is a branch containing the higher
level of detail sub-tiles.  Every thing works together really
nice.  The tree seems to be correct, all the leaf nodes at all
levels of details are correct, and their bounding spheres
have the correct center and radius.  Lots of brute force
debugging and print statements makes me believe things
are correct.

But, the same debugging and print statements show me
that the range calculated in the cull of each LOD selector
is the same for each selector.  As I move the camera
around the terrain, the range changes and I get different
culling, but it is funny because the range calculated seems
to be wrong.

So, my questions...
How is the range calculated when culling to the viewing fustrum?
What could I be doing wrong?
What should I look at to get more info?

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho

Re: [Plib-devel] GL_COLOR_MATERIAL pitfall

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

Christian Mayer wrote:
> 
> Steve Baker wrote:
> >
> > In the course of discussions on OpenGL-Gamedev, it became aparrent
> > that:
> >
> > 1) No two Guru's could agree on what *should* happen under every
> >    circumstance.
> >
> > 2) As a consequence of (1), quite a few OpenGL implementations
> >    actually get it wrong.
> 
> Can't they sit down and define a standard for OpenGL 1.3? Or are they
> already doing that?

Well, there is a standard - but it's rather hard to understand from
the wording in the specification - and the 'official' OpenGL test
suite that is run on every implementation before it's allowed to
be called 'OpenGL' doesn't have a test for this particular problem,
so it's rather easy for broken implementations to sneak past.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] GL_COLOR_MATERIAL pitfall

[<Va...@t-...>]

Steve Baker wrote:
> 
> In the course of discussions on OpenGL-Gamedev, it became aparrent
> that:
> 
> 1) No two Guru's could agree on what *should* happen under every
>    circumstance.
> 
> 2) As a consequence of (1), quite a few OpenGL implementations
>    actually get it wrong.

Can't they sit down and define a standard for OpenGL 1.3? Or are they
already doing that?

CU,
Christian

Re: [Plib-devel] GL_COLOR_MATERIAL pitfall

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

Dave McClurg wrote:

> i saw something in Kilgard's "common opengl pitfalls" page that might be
> relevant to SSG.
> see "#14. Careful Enabling Color Material" at
> 
> http://www.opengl.org/Coding/KilgardTechniques/oglpitfall/oglpitfall.html
> 
> would this explain any of the problems encounted in ppe and flightgear?

It's certainly something *like* that.

In the course of discussions on OpenGL-Gamedev, it became aparrent
that:

1) No two Guru's could agree on what *should* happen under every
   circumstance.

2) As a consequence of (1), quite a few OpenGL implementations
   actually get it wrong.


-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-devel] GL_COLOR_MATERIAL pitfall

[Dave M. <dp...@ef...>]

i saw something in Kilgard's "common opengl pitfalls" page that might be
relevant to SSG.
see "#14. Careful Enabling Color Material" at

http://www.opengl.org/Coding/KilgardTechniques/oglpitfall/oglpitfall.html

would this explain any of the problems encounted in ppe and flightgear?

--Dave McClurg

RE: [Plib-devel] mass migration to win32?

[Dave M. <dp...@ef...>]

> I would expect every plib developer has switched from
> unix to win32. (Horror!)
>
lol. i admit it. i'm still too comfy in windows.  i like MS Outlook too
much.  Haven't found a really good replacement for it under linux.  OT--
anyone have a nice email client to recommend under linux?

> Because the cvs version has a upper/lowercase problem
> for quite some time:
>
> Makefile.in of src/ssg has
>
> INCLUDES =  -I$(top_srcdir)/src/sg -I$(top_srcdir)/src/ul
>
> which I think should be
>
> INCLUDES =  -I$(top_srcdir)/src/sg -I$(top_srcdir)/src/UL
>
Ack. That was my fault. I'm a heavy win32 user and i used wincvs to add the
ul.h file. it must have made the folder name uppercase.  the UL folder
should probably be nuked and recreated as "ul".  I'll get to that monday if
Steve doesn't beat me to it.  Also, the ul.h should be placed in /usr/... so
that PPE can get to it.  all of SSG is now using the ulSetError() function.

> Something else:
> I can't get plib_examples-1.1.8.tar.gz to build with cvs plib.
> Is this correct?
>
plib_examples was not in CVS the last i checked.  when Steve puts it there,
i can help fix any problems on linux or win32.

> Enjoy your easter eggs,
thanks

--Dave McClurg

RE: [Plib-devel] Can LOD selector branches be nested?

[Vallevand, M. K <Mar...@UN...>]

Thanks.  I've tried to make this work with limited success.
But, the comment about transition ranges is my likely
culprit.  I think I'm off by some factor.  I get some
really funny fragments displayed as I move over the
terrain.  

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho


> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> Sent: Friday, April 21, 2000 12:36 AM
> To: pli...@li...
> Subject: Re: [Plib-devel] Can LOD selector branches be nested?
> 
> 
> "Vallevand, Mark K" wrote:
> > 
> > Can LOD selector branches be nested?
> 
> Yep - certainly.  You can nest arbitary glBranch derivitives to
> arbitary depth in any old order.
> 
> If you put a LOD within a LOD then the node nearest the root
> of the scene graph will be evaluated - and one of it's kids
> selected for rendering depending on range.  If that child node
> (or one of it's descendents) is a LOD node then it will then
> be evaluated and so on down the tree.
> 
> Obviously it doesn't make much sense to have the first of
> those nodes having a transition range of (say) 0 to 100meters
> and the child LOD node having a 'wider' range (say) 0 to 150meters
> since the latter will always pass (unless there's a transform
> node inbetween or something).
> 
> Generally, the child nodes would always have transition ranges
> that lie *within* the transition range of the parent LOD node.
> 
> But there is nothing to stop you ignoring that advice if you
> have good reason.
> 
> 
> -- 
> Steve Baker                  http://web2.airmail.net/sjbaker1
> sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
> sj...@ht...      (work)
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

[Plib-devel] mass migration to win32?

[Bram S. <br...@ch...>]

Hello plibbers,


Ok, the subject line is a bad joke, but:
it is weird....

I would expect every plib developer has switched from
unix to win32. (Horror!)

Because the cvs version has a upper/lowercase problem
for quite some time:


Makefile.in of src/ssg has

INCLUDES =  -I$(top_srcdir)/src/sg -I$(top_srcdir)/src/ul

which I think should be

INCLUDES =  -I$(top_srcdir)/src/sg -I$(top_srcdir)/src/UL

I wonder why only my dec-alpha gcc is affected.
Oh well, maybe I just screwed up somewhere big time.

Something else:
I can't get plib_examples-1.1.8.tar.gz to build with cvs plib.
Is this correct?

Also, some minor 64-bit clean issues:

cxx: Warning: slMODinst.cxx, line 219: conversion from pointer to smaller
          integer
          restS, restF, ihi.end-ihi.ptr, ( unsigned int ) ihi.ptr ) ;
-----------------------------------------^
cxx: Warning: slMODinst.cxx, line 221: conversion from pointer to smaller
          integer
          ( unsigned int ) ( ihi.ptr - ( ihi.wAcc >> 16 ) ) ) ;
----------^
cp: .deps/slMODinst.pp: No such file or directory

this is not to bad, because it affects only some printf args,
but getting rid of the warnings would be nice.

Enjoy your easter eggs,


     Bram Stolk


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Bram Stolk               "Linux - Why use windows, if there is a door?"
  work: br...@sa...
  priv: br...@ch...

Re: [Plib-devel] Can LOD selector branches be nested?

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

"Vallevand, Mark K" wrote:
> 
> Can LOD selector branches be nested?

Yep - certainly.  You can nest arbitary glBranch derivitives to
arbitary depth in any old order.

If you put a LOD within a LOD then the node nearest the root
of the scene graph will be evaluated - and one of it's kids
selected for rendering depending on range.  If that child node
(or one of it's descendents) is a LOD node then it will then
be evaluated and so on down the tree.

Obviously it doesn't make much sense to have the first of
those nodes having a transition range of (say) 0 to 100meters
and the child LOD node having a 'wider' range (say) 0 to 150meters
since the latter will always pass (unless there's a transform
node inbetween or something).

Generally, the child nodes would always have transition ranges
that lie *within* the transition range of the parent LOD node.

But there is nothing to stop you ignoring that advice if you
have good reason.


-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

RE: [Plib-devel] Additional PUI Widgets

[Vallevand, M. K <Mar...@UN...>]

> 
> I started using PUI over a year or so ago, but only 
> subscribed to this list
> recently.  If anybody is interested, I would like to offer a couple of
> additional widgets for PUI.  They include
> 	- arrow buttons (left, right, up, or down; single or 
> double arrows)
> 	- a large input box which can handle an arbitrary amount of text
> (still needs a bit of work)
> 	- a dial, which is a square with a line running from 
> the center to
> the circumference whose angle the user sets with the mouse
> 	- sliders with integer ranges and with two or three slides

These sound really neat.
 
> I also have a way for PUI to support multiple GLUT windows, 
> again if anybody
> is interested.

This would be great.  I have a multiple GLUT window mechanism for
PUI, too.  I'd like to see a solution that works.  Mine fails is
some odd ways, and I've shelved it.  I was going to look at it
again after I got some more stuff done is my program that was going
to use it.
 
> John F. Fay
> joh...@eg...

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho

[Plib-devel] Can LOD selector branches be nested?

[Vallevand, M. K <Mar...@UN...>]

Can LOD selector branches be nested?

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho
 

Re: [Plib-devel] Additional PUI Widgets

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

Fay John F Contr AAC/WMG wrote:
> 
> I started using PUI over a year or so ago, but only subscribed to this list
> recently.  If anybody is interested, I would like to offer a couple of
> additional widgets for PUI.  They include
>         - arrow buttons (left, right, up, or down; single or double arrows)
>         - a large input box which can handle an arbitrary amount of text
> (still needs a bit of work)
>         - a dial, which is a square with a line running from the center to
> the circumference whose angle the user sets with the mouse
>         - sliders with integer ranges and with two or three slides
> 
> I also have a way for PUI to support multiple GLUT windows, again if anybody
> is interested.

That all sounds pretty useful - do you want to email them to me?

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-devel] Additional PUI Widgets

[Fay J. F C. AAC/W. <joh...@eg...>]

I started using PUI over a year or so ago, but only subscribed to this list
recently.  If anybody is interested, I would like to offer a couple of
additional widgets for PUI.  They include
	- arrow buttons (left, right, up, or down; single or double arrows)
	- a large input box which can handle an arbitrary amount of text
(still needs a bit of work)
	- a dial, which is a square with a line running from the center to
the circumference whose angle the user sets with the mouse
	- sliders with integer ranges and with two or three slides

I also have a way for PUI to support multiple GLUT windows, again if anybody
is interested.

John F. Fay
joh...@eg...

RE: [Plib-devel] [Fwd: Model / 3D Object format that is easy to use, yet powerful? (fwd)]

[Dave M. <dp...@ef...>]

> Having worked on a couple projects that made extensive use of the .ASE
> format, I personally wouldn't choose to use that format for anything
again.
>
actual mileage may differ
i've also worked on a couple projects that made extensive use of the
.ASE format and i've been able to easily get what i need:
- vertex coordinates
- vertex colours
- texture mapping coordinates
- transform animation (absolute position,relative quats for rotation,and
scale vectors)
- mesh animation (just another definition of the mesh. could be used for
LOD. worked nicely on a shark i had to bend back and forth)
- object names
- parent heirarchy
- material properties (amb,diff,spec,shine,transparency,sub
materials,tiling,offset,textures)
sheesh. what more can you ask for?

> The problems we ran into mainly stemmed from the fact that
> the .ase exporter is just a sample plugin, and wasn't intended as a real
> file format.  As such, it is ridden with bugs, and completely unsupported.
>
perhaps, but you get the source code with the MAX SDK and the ASE exporter
works very well.  haven't encounted many bugs

> Anyways, here are the main problems we ran into:
> 1) transformations - .ase has the transformations stored in a full matrix,
>    plus the components of the matrix (rotation, scale, etc.)
>    which just happen to not match up.
>    (One of them is just totally wrong - and I don't remember which)>
>
there is a NODE_TM for each object which has a 4x4 matrix. i ignore it.
the transformation keys (TM_ANIMATION) are not stored as 4x4 matricies.

> 2) no documentation - there are several completely unintuitive things
>    about the 3ds max architecture that you become exposed to but using
.ase.
>    For example:
>    2a) normals - normals are sometimes in world space, and sometimes in
object space,
>        and the space they're in is determined by whether they're being
animated,
>        whether their parent transforms are being animated, etc.
>
the normals do seem odd.  i ignore them.  i only needed face normals which
are easy enough to compute.  i suppose you could compute vertex normals too.

>    2b) ignore rotation flags - there are a couple flags on each matrix
>        that specify whether or not to inherit its parent's
rotation/scale/translation,
>        which is awkward for the programmer, albeit useful for the artist.
>        The problem is, the flag means exactly the opposite of what it's
named.
>        (inheritRotation true -> don't inherit parent's rotation)
>
thanks for the tip.  i'm currently implementing parent heirarchy with
animation now.

> 3) animation - keyframes for mesh animation and transform animation aren't
> sync'ed, so if you have an animation with both, you need to untransform
all the
> mesh animations at each transform animation keyframes, which requires you
to exactly
> mimic the interpolation going on within max - which isn't trivial for TCB
> interpolated quaternions. ;)
>    (We were able to do this last only after bugging the developers for
their
> 3dsmax TCB interpolation code - Ugh - most of the comments in the batch of
10
> files were commented out code, and the one classic: "However, I
> think this code is incorrect.")
>
in the ASE dialog window, you can tell max to force a sample every frame so
it should be easy to mimic transform animation.  also, in the case of mesh
and transform animation, you could just do the mesh animation and put the
transform animation on a skeleton and link them together.  that is how i've
seen it done (ie: bones)

> I might suggest the .obj file format,
> for which there are free exporters available from max,
> although, of course, it won't export animation or skeletons.
> It's trivial to read, but again, it's probably not
> as fully functional as you may need.
>
yes.  obj is very nice and clean.  glTron uses obj format.
no animation or vertex colours -- ouch!

> The best alternative is, given the time and motivation,
> is to write a plugin that exports the data you want,
> but even this isn't foolproof, given the bug in max
> that causes IK to be unavailable to any plugin.
>
who wants to write a plugin?
perhaps a hack to the ASE "sample" plugin to fix bugs would be useful.
the best alternative to that is to use ASE with work-arounds.
ASE is the most complete and flexible ascii format that MAX exports
i'm sticking with ASE.

> Oops, my coworked just corrected my list of problems.
> The normals problem is actually part of a larger one:
>
> transforms and vertices are in global space,
> normals are usually in local space, unless they're below a space warp,
> (which isn't written into the .ase file, so there's no way to know this)
> in which case they're also in global space.
>
> mesh keyframes are in local space,
> transformation keyframes are in global space,
> and rotational transformation keyframes are in global space,
> but every keyframe except the first is a relative keyframe.
> (all other keyframes (mesh and non-rotational transformation) are
absolute.
>
i would agree except that i have found mesh keyframes to be in global space.
so... everything except normals is in global space.

> So, I'd suggest using .obj (and .mtl) if you can,
> and if not, seriously consider spending the time
> writing a 3dsmax plugin. (or a Maya plugin, or whatever)
>
yes. if your requirements are simple then use .obj (and .mtl)
otherwise, stick with .ase since it is the best thing around
short of writing your own 3dsmax plugin (yuck!).

besides, any plugin of your own design would just be
yet another format to upgrade and fix when 3ds decides
to upgrade max.  at best, it would be as good as .ase
with a few bug fixes.  just send a patch to 3ds for the
"sample" .ase code in the SDK.

-- Dave McClurg
dav...@dy...

[Plib-devel] [Fwd: Model / 3D Object format that is easy to use, yet powerful? (fwd)]

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

I spotted this on the Opengl-Gamedev list, it seemed like
it may be of some interest to this list.

It's talking about the ASE file format - and some
known problems with the 3DS ASE writer...

> ---------- Forwarded message ----------
> From: Joe Demers <JD...@nv...>

> Having worked on a couple projects that made extensive use of the .ASE
> format,
> I personally wouldn't choose to use that format for anything again.
> 
> The problems we ran into mainly stemmed from the fact that
> the .ase exporter is just a sample plugin, and wasn't intended as a real
> file format.
> As such, it is ridden with bugs, and completely unsupported.
> (That wasn't intended as a cut on the author - I mentioned it's just a
> sample plugin)
> 
> Anyways, here are the main problems we ran into:
> 1) transformations - .ase has the transformations stored in a full matrix,
>    plus the components of the matrix (rotation, scale, etc.)
>    which just happen to not match up.
>    (One of them is just totally wrong - and I don't remember which)
> 2) no documentation - there are several completely unintuitive things
>    about the 3ds max architecture that you become exposed to but using .ase.
>    For example:
>    2a) normals - normals are sometimes in world space, and sometimes in
> object space,
>        and the space they're in is determined by whether they're being
> animated,
>        whether their parent transforms are being animated, etc.
>    2b) ignore rotation flags - there are a couple flags on each matrix
>        that specify whether or not to inherit its parent's
> rotation/scale/translation,
>        which is awkward for the programmer, albeit useful for the artist.
>        The problem is, the flag means exactly the opposite of what it's
> named.
>        (inheritRotation true -> don't inherit parent's rotation)
> 3) animation - keyframes for mesh animation and transform animation aren't
> sync'ed,
>    so if you have an animation with both, you need to untransform all the
> mesh animations
>    at each transform animation keyframes, which requires you to exactly
> mimic
>    the interpolation going on within max - which isn't trivial for TCB
> interpolated quaternions. ;)
>    (We were able to do this last only after bugging the developers for their
> 3dsmax
>    TCB interpolation code - Ugh - most of the comments in the batch of 10
> files
>    were commented out code, and the one classic: "However, I think this code
> is incorrect.")
> 
> I might suggest the .obj file format,
> for which there are free exporters available from max,
> although, of course, it won't export animation or skeletons.
> It's trivial to read, but again, it's probably not
> as fully functional as you may need.
> 
> The best alternative is, given the time and motivation,
> is to write a plugin that exports the data you want,
> but even this isn't foolproof, given the bug in max
> that causes IK to be unavailable to any plugin.
> 
> Oops, my coworked just corrected my list of problems.
> The normals problem is actually part of a larger one:
> 
> transforms and vertices are in global space,
> normals are usually in local space, unless they're below a space warp,
> (which isn't written into the .ase file, so there's no way to know this)
> in which case they're also in global space.
> 
> mesh keyframes are in local space,
> transformation keyframes are in global space,
> and rotational transformation keyframes are in global space,
> but every keyframe except the first is a relative keyframe.
> (all other keyframes (mesh and non-rotational transformation) are absolute.
> 
> Whew.
> Sorry for the novel,
> but that's finally it.
> 
> So, I'd suggest using .obj (and .mtl) if you can,
> and if not, seriously consider spending the time
> writing a 3dsmax plugin. (or a Maya plugin, or whatever)

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

R: R: [Plib-devel] Update on 3ds loader

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

Wolfram Kuss wrote:

> Are you (Per/Paolo) working under Windo$?

Yes, NT4 at office and 98 at home. I use the full Cygnus dev-sys (gcc =
2.9.2).=20

> Paolo, shall I send you the file?

Yes, please.
To all: what about to start using the anonymous FTP space for test =
cases? (even if I got problems to go to =
ftp://plib.sourceforge.net/pub/plib/)

For now you could try to put such initialization in function =
ssgLoad3ds()
:
  mat_tfnames =3D new char*[MAX_MATERIALS];	// this line already exists
  for ( int _i=3D0; _i < MAX_MATERIALS; _i++ )
    mat_tfnames =3D (char *)NULL;

This is implemented in experimental version of the loader at =
ftp://ftp.cira.it/paolo/plib/ssgLoad3ds.cxx that you can test in the =
meanwhile.
I'm not able to test such modification since my model, that I'll manage =
to distribute soon as test case, is fully textured.

To Per:
- this version also set node name for VTable nodes to the actual object =
name read in the file - previously the related material name was given =
to the node (I did it, sorry). This is useful for later navigation in =
the graph, e.g. to set/change properties to nodes for which the 3DS name =
is known (in my case: don't lit the far cylinder showing the sky =
texture);
- thanks for the strdup() - I didn't realize how useful it is, but, once =
discovered, I'm using it even too often!

-----Messaggio originale-----
Da:	Wolfram Kuss [SMTP:w_...@rz...]
Inviato:	venerd=EC 7 aprile 2000 18.20
A:	pli...@li...
Oggetto:	Re: R: [Plib-devel] Update on 3ds loader

My problem is not that something is loaded too often
or some texture is not found, but that it crashes because it is=20
dereferencing an invalid pointer.

I am working under (on??) Windows NT.
It crashes while loading chevy.3ds because it tries to
reference an undefined pointer (the hex address is cdcdcdcd,
which is Visual C++ way of saying bad pointer).

I set a break point in parse_material and another one in=20
parse_mapname.
The first three times it finds a breakpoint is in
parse_material. Then it goes into parse_mapname.
num_materials is three.

mat_tfnames is obviously a array of pointers. The array is defined.
However, the pointers are not.

MAYBE the first three materials are un-textured,
the texturenames are therefore not defined and when it=20
finds the first mapname it tries to compare it to the undefined,
previous ones?

Are you (Per/Paolo) working under Windo$?

Paolo, shall I send you the file?

Per, have you looked at the newest CVS-code, perhaps=20
it is different from the code you have? Do you use MSVC 6?
Do you do a debug build?

Bye bye,
Wolfram.

_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel