plib-devel

Re: [Plib-devel] ssg Leaf call backs

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

Steve Baker writes:
> Many, many moons ago, you asked me if I thought putting the sky into
> SSG was a good idea - and I said then that you'd probably be better
> off to do it in OpenGL because it needs some rather wierd tricks.
> 
> My Simulator visual system that I work on in my 'paying job' does
> the sky in OpenGL - simply because Performer can't hack doing things
> in fixed orders.

Yup, I remember that but let me present an opposing view point.

For someone like you with immense OpenGL experience what you suggest
is a viable option and probably the best choice for maximizing
performance and quality.  If, in the process, you'd accidentally get
your opengl state out of whack, you have enough experience to look at
the result and [hopefully] immediately determine what you screwed up.
Then it would be a pretty easy fix for you.

Then there is the rest of us, many of which are just starting out with
opengl, or don't have a deep level of understanding of opengl
textures, blending, alpha_test, colors, lighting, fogging, what
activates them, why they work, what they look like when something is
messed up, etc.

My little excercise of building the sky in ssg has forced me into
understanding a lot of these things at a much deeper level which is
good for me, but I'm by no means and expert.  [yet] :-)

However, the average person just starting out with opengl games, sims,
visualization, likely wouldn't understand all the underlying nuances
of one or more of the states and blend functions I use to create the
sky.  Providing the sky in raw, hand crafted opengl might yield
extremely strange results for them if they blindly plug it in and the
sky finishes and leaves things in some weird state.

By building the sky in ssg, developers that are newer to opengl would
have a much better chance at dropping it into their scene graph and
having it just work.

> Anyway, perhaps what we need to look at here is the possibility of
> adding some kind of ssgNoSortBranch node type that promises to
> draw things in a specific order...I don't really like that because
> it implies considerable nastiness when I *DO* get around to doing
> material sorting.

Yes ... this seems like a less generalize solution.

> The 'official' way to do this stuff in SGI's Performer scene graph
> API is to allow the user to define their own sorting 'buckets'
> analogous to SSG's "opaque" and "translucent" buckets.  You can then
> tell Performer what order to render the buckets.  Material sorting
> then happens only within one bucket.

Yes ... that's essentially option (3) in my previous message, except
attaching the hint to the state which makes a lot more sense now that
I think about it. :-)

> In that way, you could put the first pass of the sky in bucket
> zero, the second pass into bucket one, the rest of the scene
> into bucket two except for the translucent polygons in bucket
> three.

This imposes additional work on the application writer, but it's all
fairly straight forward and could be explained in the sky
documentation.

> That might get a tad complex and would have to be rewritten
> when I get around to doing material sorting anyway.  Once
> we have material sorting, the simplest fix will be to simply
> tell SSG which order the materials are to be rendered in - then
> you could pick special materials for the sky and tell them to
> render first - in whichever order you need.

This sounds like a pretty good long term solution.

> So...what should be done right now?
> 
> Nothing.  At present, child nodes are rendered in order except
> where there are translucent ssgLeaf nodes.

Yes, things can be made to work right now.

> Hence, right now you can get away with it - and I'll promise to
> provide an 'ssgState::renderPriority()' call in the future
> when material sorting gets implemented.
> 
> Another possibility would be to put each phase of the sky rendering
> into a separate ssgScene and just call ssgCullAndDraw for each one
> in turn.
> 
> Ugly - but do-able right now and not likely to break in the future.

And you pay a slight penalty in additional unneeded state changes
since you call state->force() at the start of each ssgCullAndDraw().

> > 1) Perhaps a branch could have a marker that says below this point
> > process things in exact order.
> 
> I don't like that.

Agreed, but I was just brain storming ...

> > 2) Perhaps the sky could be implimented as a separate ssg scene graph
> > that is marked as do not sort anything in this scene graph.
> 
> Same problem...unless each phase is a separate scene graph (as I suggested
> earlier).

Yup ...

> > 3) Perhaps we could assign sorting hints to each leaf node (such as an
> > integer value).  ssg could sort by this hint first, and then do
> > whatever it wanted to do for all the nodes with the same sorting hint.
> 
> Well, not on each leaf node - but perhaps on each ssgState.

Yes, good point ... attach the hint/bucket to each ssgState.

> > It would be great if ssg could handle a few more state types.  The
> > primary things I am interested in now are:
> > 
> > GL_DEPTH_TEST
> > GL_FOG
> > glBlendFunc( SRC, DEST )
> 
> Yep.  I'll look at doing this.  It shouldn't be too tricky.

Great, thanks!

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] C++ Philosophy Question

[Bill W. <bil...@ch...>]

Well, I started this thread because I wanted to know what to stick to in coding for plib, and I appreciate the info.  I do have a few parting shots^H^H^H^H^Hthoughts on this, however.

(I've kind of mixed up Dave's and Steve's replies, sorry).

>> STL would just be another dependency
>> If you just need a list you can make it yourself
>> like the ssgVertexArray

Reinventing  (or reimplementing) the wheel?-

>
>So far, nothing in STL seems worth the hassle. There are
>still too many incompatible versions floating around out
>there - and systems that don't have it installed, etc.
>
>I watched the L-O-N-G thread that went on in the FGFS
>mailing list when STL was first used.  It convinced me
>that I can do without it.
>

There _are_ problems with STL across implementations (even using Visual C++ 6.0, you'd better be using Service Pack 3).  This is unfortunate, because you can write a lot of nice, concise code quickly using the STL containers.  I've come to like STL, but I agree that portability is a problem (which I sort of realized as soon as I posted the question).  Oh well...

>
>> *** templates, exceptions, references, operator overloading
>
>Well, some of these things are just eye candy. (eg Operator
>overloading) - some obfuscate code to a dangerous degree (eg
>References) - others are STILL not portable enough for my
>liking (Templates, exceptions).

I agree about exceptions (but preferable to unceremonious exits ;), templates can be OK if you stick to basics, references are more precise/less error prone than pointers when e.g. a function arg. or member cannot/should not be NULL (and cannot/should not be changed dynamically), and I think there are cases where not overloading operator = (or at least hiding it) for a class can cause trouble. 

> 
>> *** namespaces
>> 
>> i like them. any thoughts?

I suspect namespaces are (at least currently) a bit too subtle; I recall seeing some hair-raising examples of their potential for misuse in CUJ/C++ Report (one of those).  I'll try to dig them up if anyone's interested.

Anyway, that's it for religion, time to write some code.

Bill

Re: [Plib-devel] Another stumper ...

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

Steve Baker writes:
> It's perfectly possible that there is something broken in there.
> 
> I've hacked it around several times in an attempt to get it to
> work in the face of the confusions that I explained before.
> 
> I think a comprehensive test program is needed - something that
> we could ask a bunch of people to test on different implementations.

What I ought to do is just try to draw a simple object with
glColorMaterial() off and trying to see if I can get anything sensible
on the screen.

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] Importers/Exporters

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

Per Liedman <li...@ho...> wrote:

>On Mon, 20 Mar 2000, Wolfram Kuss wrote:
>
>> *.3ds writer: Polytrans says about the object:
>> not 3ds file or version not recognized.
>
>Hmmm...AFAIK there is no plib 3ds-writer, and that's one plausible reason for
>this error :-)

:-)
So PolyTrans is absolutely right. Well, it shows again that there
should be a warning: When you tell PPE to write test.3ds, it does.
So, you think, it is a *.3ds-file :-).

>> *.3ds crashed. 
>
>I want that model, and I want it NOW! ;-)

I am sending my test-objects to you and Dave via e-mail NOW :-).
BTW, here are some URLs for free models.

*.3ds:
http://www.personal-connections.com/arkon/models/freemodels/index.html

MANY *.3ds and *.DXF, a few *.obj (in anatomy and animals)
www.3dcafe.com

Sample model of a dolphin in some file formats.
http://www.flashfire.com/

Sample model of a helicopter in some file formats and in some sizes
(LODs).
www.viewpoint.com


More links (I didnt try them):
www.3dcafe.com

I am still looking for more textured models, if I find some, I will
send them to you.

>
>Best regards,
>Per Liedman

RE: [Plib-devel] C++ Philosophy Question

[Paul B. <pbl...@di...>]

> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> 
> I'm told that STL will be a part of the C++ standard in
> the next revision of the ANSI spec - that means that it'll
> be usable in a couple of years when all the older compilers
> catch up.

STL is part of the ANSI C++ spec now.  The next revision will
include a number of clarifications on implementation of some
of the STL containers (like vector will be required to be
contiguous memory, etc...).

However, I agree with you that it is still not uniformly and
consistently supported without resorting to either crazy 
configuration macros and/or relying on a particular implementation
(i.e. sgi-stl, stlport, etc...)

Paul

Re: [Plib-devel] Another stumper ...

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

"Curtis L. Olson" wrote:
> 
> Sounds like the best solution is to try to stick to a consistant
> scheme ... either use glColorMaterial every where, or don't use it at
> all.  However, I've had very poor luck using anything but
> glColorMaterial in ssg.  I get what I expect when I use
> glColorMaterial.  I rarely get what I expect when I don't.  This could
> be a problem with my understanding and expectations, or perhaps it
> could be that something somewhere isn't quite right in the state
> handling?

It's perfectly possible that there is something broken in there.

I've hacked it around several times in an attempt to get it to
work in the face of the confusions that I explained before.

I think a comprehensive test program is needed - something that
we could ask a bunch of people to test on different implementations.

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

Re: [Plib-devel] C++ Philosophy Question

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

Dave McClurg wrote:
> 
> I recently asked some related questions so i'll share what I know:
> 
> *** Naming conventions:
> 
> for public symbols in PLIB module 'XX' (where 'XX' is: SL, SSG, SG, PU, FNT):
> 
> #define's, enum tags                 XX_ALL_CAPITALS
> functions/classes/structs/typedefs   xxMixedCase
> 
> For private symbols, I use all_lowercase unless they would pollute
> the name space - in which case I use a leading underscore _xxMixedCase

Right.

> *** Dependencies
> 
> To use PLIB you need only GLUT, OpenGL and C++.
> keeping more dependencies out of PLIB is a design goal
> 
> STL would just be another dependency
> If you just need a list you can make it yourself
> like the ssgVertexArray

So far, nothing in STL seems worth the hassle. There are
still too many incompatible versions floating around out
there - and systems that don't have it installed, etc.

I watched the L-O-N-G thread that went on in the FGFS
mailing list when STL was first used.  It convinced me
that I can do without it.

I'm told that STL will be a part of the C++ standard in
the next revision of the ANSI spec - that means that it'll
be usable in a couple of years when all the older compilers
catch up.

Remember, portability is the number one goal of PLIB.

> *** templates, exceptions, references, operator overloading
> 
> like honey. icky sticky stuff.  can't see why pooh bears like it
> once in a while it can be handy but
> might as well keep it simple in a portable library like PLIB

Well, some of these things are just eye candy. (eg Operator
overloading) - some obfuscate code to a dangerous degree (eg
References) - others are STILL not portable enough for my
liking (Templates, exceptions).
 
> *** namespaces
> 
> i like them. any thoughts?

Still rather new.  Don't forget that people use PLIB
on systems like Solaris, MSVC 5, Irix 5.x - some of
those compilers are pretty old.
 
Having made all those excuses - I also have to confess
to being something of a minimalist when it comes to
coding.  C++ (like UNIX, OpenGL, HTML and others)
had 99% of what it needed in the very first version.

Once the design got out of the hands of the original
author, design-by-committee took over.

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

Re: [Plib-devel] ssg Leaf call backs

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

"Curtis L. Olson" wrote:

> Hmmm ... my sky implimentation depends on certain parts of it being
> drawn in a particular order.  I might be able to fudge a few things,
> but I'm not sure if that would always work.

Many, many moons ago, you asked me if I thought putting the sky into
SSG was a good idea - and I said then that you'd probably be better
off to do it in OpenGL because it needs some rather wierd tricks.

My Simulator visual system that I work on in my 'paying job' does
the sky in OpenGL - simply because Performer can't hack doing things
in fixed orders.

Anyway, perhaps what we need to look at here is the possibility of
adding some kind of ssgNoSortBranch node type that promises to
draw things in a specific order...I don't really like that because
it implies considerable nastiness when I *DO* get around to doing
material sorting.

The 'official' way to do this stuff in SGI's Performer scene graph
API is to allow the user to define their own sorting 'buckets'
analogous to SSG's "opaque" and "translucent" buckets.  You can then
tell Performer what order to render the buckets.  Material sorting
then happens only within one bucket.

In that way, you could put the first pass of the sky in bucket
zero, the second pass into bucket one, the rest of the scene
into bucket two except for the translucent polygons in bucket
three.

That might get a tad complex and would have to be rewritten
when I get around to doing material sorting anyway.  Once
we have material sorting, the simplest fix will be to simply
tell SSG which order the materials are to be rendered in - then
you could pick special materials for the sky and tell them to
render first - in whichever order you need.

So...what should be done right now?

Nothing.  At present, child nodes are rendered in order except
where there are translucent ssgLeaf nodes.

Hence, right now you can get away with it - and I'll promise to
provide an 'ssgState::renderPriority()' call in the future
when material sorting gets implemented.

> It's nice to be able to turn off depth testing and draw the dome first
> as sort of a clear screen operation.  The sun halo needs to get drawn
> before the sun or it could end up overdrawing it.  It would be nice to
> draw the planets and stars after the moon is drawn so that we don't
> have to see stars showing through the dark side or the shadows of the
> moon.  The sky will likely be drawn out towards the far clip plane
> where the z buffer typically gets very inaccurate, so it's nice to be
> able to depend on drawing order and not the z-buffer.

Yep.

Another possibility would be to put each phase of the sky rendering
into a separate ssgScene and just call ssgCullAndDraw for each one
in turn.

Ugly - but do-able right now and not likely to break in the future.

> 1) Perhaps a branch could have a marker that says below this point
> process things in exact order.

I don't like that.
 
> 2) Perhaps the sky could be implimented as a separate ssg scene graph
> that is marked as do not sort anything in this scene graph.

Same problem...unless each phase is a separate scene graph (as I suggested
earlier).

> 3) Perhaps we could assign sorting hints to each leaf node (such as an
> integer value).  ssg could sort by this hint first, and then do
> whatever it wanted to do for all the nodes with the same sorting hint.

Well, not on each leaf node - but perhaps on each ssgState.
 
> > It *definitely* doesn't work - even now - because of the
> > transparency thing - and even if you are getting away with it right
> > now, I can promise to break your code sometime in the future.
> 
> Yes, that is why I'm not marking my transparent sky bits as
> setTransparent() because it fouls up the sort order

That's certainly OK for now.  The setTransparent flag is only used
for sorting.

> It would be great if ssg could handle a few more state types.  The
> primary things I am interested in now are:
> 
> GL_DEPTH_TEST
> GL_FOG
> glBlendFunc( SRC, DEST )

Yep.  I'll look at doing this.  It shouldn't be too tricky.
 
> Between this, and providing a way to guarantee drawing order, my sky
> will be in good shape.

OK.

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

Re: [Plib-devel] Importers/Exporters

[Per L. <li...@ho...>]

On Mon, 20 Mar 2000, Wolfram Kuss wrote:
> *.3ds loader: crashes with the two larger files, loads the small file
> ok. The colours of the small object seemed wrong.

Could you *pleeeeeaaaaase* make the models available for download somewhere?
Since I don't own a 3d editor of any kind (waiting for you guys to make PPE
:-), I have a really hard time testing my own code... it worked with the five
3ds files I have.

> *.3ds writer: Polytrans says about the object:
> not 3ds file or version not recognized.

Hmmm...AFAIK there is no plib 3ds-writer, and that's one plausible reason for
this error :-)

> *.3ds crashed. 

I want that model, and I want it NOW! ;-)

Best regards,
Per Liedman

-- 
   / Per Liedman
  / li...@ho...
 / www.mdstud.chalmers.se/~md6pl
/ 031-825659 / 0705-520455

Re: [Plib-devel] Importers/Exporters

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

Wolfram Kuss wrote:
>I tested some importers and exporters.
excellent. please send me the DXF and OBJ
test files and i'll fix the problems for those formats.
i am very much interested in textured objects
in either DXF or OBJ format.

thanks,
--Dave
dp...@ef...

Re: [Plib-devel] Another stumper ...

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

Sounds like the best solution is to try to stick to a consistant
scheme ... either use glColorMaterial every where, or don't use it at
all.  However, I've had very poor luck using anything but
glColorMaterial in ssg.  I get what I expect when I use
glColorMaterial.  I rarely get what I expect when I don't.  This could
be a problem with my understanding and expectations, or perhaps it
could be that something somewhere isn't quite right in the state
handling?

Regards,

Curt.

Steve Baker writes:
> I am totally brain-fried over this.  I've seen the same problem in
> my own code - and the effect seems to vary from one OpenGL
> implementation to another.
> 
> The problem seems to relate to the order of operations when enabling
> glColorMaterial - or something like that.
> 
> I asked the Guru's on OpenGL-Gamedev to explain how this is *supposed*
> to work - and it rapidly became apparrent that even amongst the people
> who wrote the OpenGL spec, they don't 100% agree on what should happen
> in some of the darker corners of the API.  Given that, it's not
> entirely suprising that some OpenGL drivers get it wrong.
> 
> I've tried a variety of work-arounds - but whatever I do seems to
> flake on some other driver.
> 
> IIRC, the coe of the misunderstanding is this:
> 
>   When you use glColorMaterial to tell opengl to use glColor to
> set the current material colour, does it tell the renderer to use
> the glColor colour for that component or does it tell the material
> to change it's colour to whatever glColor says.
> 
> You may need to think about that distinction carefully.
> 
> This means that if you do something like:
> 
>    glMaterial ( ...AMBIENT...BLUE ) ;
>    glColorMaterial ( ...AMBIENT... ) ;
>    glEnable ( GL_COLOR_MATERIAL ) ;
>    glColor ( RED ) ;  /* Set current ambient colour to RED. */
>    glDisable ( GL_COLOR_MATERIAL ) ;
>    draw something ;
> 
> ...the resident guru's couldn't decide whether the current ambient
> colour is:
> 
> * BLUE - because disabling the ColorMaterial means that
>   the renderer switches to using the glMaterial colour - which
>   was set to BLUE
> 
> * RED - because the glColor command changed the current material's
>   ambient colour to RED and even though we've now disabled the
>   ability to change the glMaterial colour future glColor commands.
> 
> Well, this is just one example of the mess we are in here.  IIRC,
> it got deeper than that.
> 
> This stuff doesn't matter for most programs - but when you are
> trying to use lazy evaluation of state change, it's a pain.
> 
> I think what's needed is to write some simple OpenGL test
> programs and to try them on a variety of machines.
> 
> -- 
> 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

-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] ssg Leaf call backs

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

> "Curtis L. Olson" wrote:
> > It would be convenient to be able to attach pre/post draw call backs
> > to branch nodes as well as leaf nodes.  ssg allows me to do this now,
> > but it never calls the functions attached to branches, only leaf
> > nodes.

Steve Baker writes:
> The trouble is that leaf nodes are not rendered in order - even though
> I don't (yet) sort by material property, I do render translucent leaf
> nodes after all the opaque nodes.
> 
> Hence, if a branch node were to contain both translucent and opaque
> leaves, there would be no good time to call the callbacks.
> 
> In future (when I get around to some material sorting), this would be
> an even bigger problem.

Hmmm ... my sky implimentation depends on certain parts of it being
drawn in a particular order.  I might be able to fudge a few things,
but I'm not sure if that would always work.

It's nice to be able to turn off depth testing and draw the dome first
as sort of a clear screen operation.  The sun halo needs to get drawn
before the sun or it could end up overdrawing it.  It would be nice to
draw the planets and stars after the moon is drawn so that we don't
have to see stars showing through the dark side or the shadows of the
moon.  The sky will likely be drawn out towards the far clip plane
where the z buffer typically gets very inaccurate, so it's nice to be
able to depend on drawing order and not the z-buffer.

1) Perhaps a branch could have a marker that says below this point
process things in exact order.

2) Perhaps the sky could be implimented as a separate ssg scene graph
that is marked as do not sort anything in this scene graph.  This
would be one way to ensure that the sky would be drawn before anything
else ... at the expense of a few extra state changes (negligable?)
because of state->force() which is called at the start of each
ssgCullAndRender().

3) Perhaps we could assign sorting hints to each leaf node (such as an
integer value).  ssg could sort by this hint first, and then do
whatever it wanted to do for all the nodes with the same sorting hint.

4) Or, perhaps you could suggest ways to make sure the sky gets drawn
properly in the face of arbitrary reordering.

I can see problems with (1).  A global sort/do-not-sort flag on each
scene graph (2) would probably be the quickest easiest solution and
has minimal impact on existing users.  (3) would probably be the most
generalized solution, but could also add a lot of complexity to ssg's
internals.  (4) would involve extra work on my part so that's
definitely a last resort. :-)

> It *definitely* doesn't work - even now - because of the
> transparency thing - and even if you are getting away with it right
> now, I can promise to break your code sometime in the future.

Yes, that is why I'm not marking my transparent sky bits as
setTransparent() because it fouls up the sort order

> > Or we could be wasteful and attach the callback to every leaf node in
> > a sub tree, but I'd rather not do that either, but it would be the
> > safest I suppose.
> 
> Yep.  I guess that's what you need to do.  :-(

It's tempting to write a lazy state manager for all the states I need
to use that ssg doesn't exert influence over.  But that would be
really ugly (tm).

> ...or call the per-branch callbacks multiple times - once for each batch
> of its child nodes.  That would be pretty ugly to implement.
>  
> > Right now the things I'm interested in doing with callbacks is to set
> > blend modes and depth testing.  In some cases here it's just fine to
> > set these on a per leaf basis, but in other cases it would be nice to
> > be able to set these on a per-subtree basis.
> 
> Sounds like I need to dump those things into ssgState so that they can
> be done without callbacks.

It would be great if ssg could handle a few more state types.  The
primary things I am interested in now are:

GL_DEPTH_TEST
GL_FOG
glBlendFunc( SRC, DEST )

Between this, and providing a way to guarantee drawing order, my sky
will be in good shape.

Regards,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

[Plib-devel] Importers/Exporters

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

Hi,

I tested some importers and exporters.
I used three files with 36000, 18000 and 550 polygons.
*.3ds loader: crashes with the two larger files, loads the small file
ok. The colours of the small object seemed wrong.
*.3ds writer: Polytrans says about the object:
not 3ds file or version not recognized.
However, we don't have the newest PolyTrans.
*.dxf loader: Always reads exactly one triangle :-).
*.dxf writer: Polytrans thought, it would be an ASCII file, which it
wasn't.
*.obj loader: works, hallelujah!
*.obj writer: Polytrans says:
password for encrypted file xxxx is wrong. Import aborted
VRML import: crashes on all three files, both VRML1.0 and VRML 2.0. 

BTW, when I "save as" and give a nonsense extension, like "hhh", there
is no warning. This is quite dangerous, since you think, plib can
write wrl etc.

Besides these three objects, I tried two *.dxf files. Both loaded, but
all polygons were converted into triangles by ignoring the rest of the
vertices, so one quad became one triangle. In one of the files, there
was also a nonsense triangle, probably with wrong vertex coordinates.

Lastly, I tested a simple textured box. I wasn't able to load it
textured into PPE with any format. That maybe due to problems with
either polytrans or the texture-path or the texture-format, or maybe
with the file loaders.

*.3ds crashed. *.wrl loaded something, but it wasn't even a box.
*.obj worked, apart from the missing texture. *.dxf gave the by now
familiar triangle.

Bye bye,
Wolfram Kuss.

Re: [Plib-devel] C++ Philosophy Question

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

I recently asked some related questions so i'll share what I know:

*** Naming conventions:

for public symbols in PLIB module 'XX' (where 'XX' is: SL, SSG, SG, PU, FNT):

#define's, enum tags                 XX_ALL_CAPITALS 
functions/classes/structs/typedefs   xxMixedCase

For private symbols, I use all_lowercase unless they would pollute
the name space - in which case I use a leading underscore _xxMixedCase

*** Dependencies

To use PLIB you need only GLUT, OpenGL and C++.
keeping more dependencies out of PLIB is a design goal

STL would just be another dependency
If you just need a list you can make it yourself
like the ssgVertexArray

*** templates, exceptions, references, operator overloading

like honey. icky sticky stuff.  can't see why pooh bears like it
once in a while it can be handy but
might as well keep it simple in a portable library like PLIB

*** namespaces

i like them. any thoughts?

Re: [Plib-devel] C++ Philosophy Question

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

Bill Weiland wrote:
> 
> Hi all:
> 
> Not to start any religious debates here, but are there any guiding principles in use of C++ language/library features for developers on plib?  I'd like to make use of STL and standard string-s, for example, but it has not appeared in the existing codebase (that I've seen), and I wanted to make sure that I'm not creating problems for other users (depending on what version of what compiler one uses, this might not fly).  A few other constructs I haven't seen used (much?) are templates, references, operator overloading - do people feel these are trouble-prone?

STL can be done in a way that works. But you have to be careful about
the namespace. MSVC only lets you write e.g. std::cerr (except you are
using the 'using' operator). But most of that can be handled with one
compatibility file. IMHO it'd be great for PLIB to have one (so that
e.g. FGFS or PPE doesn't need one itself). As soon as we've got one
there wouldn't be any (compatibility) factor limiting our STL use.

I know that Steve doesn't like operator overloading much => it isn't
used in PLIB (afaik). I don't know how restrictive he's about it now as
PLIB is public... (youst to be prepared when you ask him: get enough
fire extinguishers...)

References are also not too welcome to Steve (afaik). But I think that
he accepts const references to save copying.

I think that templates might not be very portable - but any compiler
that supports STL should support templates... So I dunno why it's not
used.

CU,
Christian

[Plib-devel] C++ Philosophy Question

[Bill W. <bil...@ch...>]

Hi all:

Not to start any religious debates here, but are there any guiding principles in use of C++ language/library features for developers on plib?  I'd like to make use of STL and standard string-s, for example, but it has not appeared in the existing codebase (that I've seen), and I wanted to make sure that I'm not creating problems for other users (depending on what version of what compiler one uses, this might not fly).  A few other constructs I haven't seen used (much?) are templates, references, operator overloading - do people feel these are trouble-prone?

Thanks for any guidance!

Bill Weiland

[Plib-devel] Changes to ssgLoad and ssgSave.

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

I've hacked ssgLoad and ssgSave to change the way that they connect
file name extensions to file formats.

There is now a table of file name extensions and the corresponding
loaders and writers:

static _ssgFileFormat formats[] =
{
  { ".3ds", ssgLoad3ds , NULL       },
  { ".ac" , ssgLoadAC3D, ssgSaveAC  },
  { ".ase", ssgLoadASE , ssgSaveASE },
  { ".dxf", ssgLoadDXF , ssgSaveDXF },
  { ".obj", ssgLoadOBJ , ssgSaveOBJ },
  { ".ssg", ssgLoadSSG , ssgSaveSSG },
  { ".tri", ssgLoadTRI , ssgSaveTRI },
  { ".wrl", ssgLoadVRML, NULL       },
  { NULL  , NULL       , NULL       }
} ;

If you add a loader or writer, just add it into
the table which can be found in ssg.cxx.

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

Re: [Plib-devel] DXF load/save

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

Bill Weiland2 wrote:
> 
> Yes, actually I saw Dave's messages about OBJ well after he had
> committed the code; I had some other diversions, but I still need an OBJ
> loader that does textures, so I will do it.  The only question is
> whether I should just dump my version and add textures to Dave's loader,
> or continue with mine.

Yep - it's a hard call.  Make sure you tell this list what you decide
so that Dave knows not to tread on what you are doing.

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

[Plib-devel] gtl: the Generalized Time Lib

[Durk T. <d.t...@ch...>]

[I'm cross posting this to both plib-devel and fgfs-devel, since I believe it
might be relevant for both

Steve Baker wrote:

> Durk Talsma wrote:

[SNIP]

>

> The code that calculates the right position of the sun, moon, and planets
> > currently pretty much intertwined with the rest of FlightGear, and one of my
> > intentions is to seperate this from the core of the simulator code.
>
> Good.
>
> > Because
> > Astronomy and time code is pretty much intertwined, I'm currently thinking of
> > reorganizing this into a single time/astromomy lib. Though I'm open to
> > including this code in plib as well, I'm not sure if this is the right place
> > for this lib to go.

Ok, I've just finished the first stab at writing a generally usable time lib,
which I gave the working title of gtl (see subject). Today, I've implemented the
first class, named Time, which handles all non-local time., ie. greenwich mean
time, UTC, julian, and Greenwich Sidereal time. It turns out pretty similar to
what Steve proposed, and consists mainly of recycled FlightGear code:

>
> I guess we have some layering here:
>
>         date + local time + lat/long position
>                        |
>                        |
>                        v
>           universal time + lat/long position
>                        |
>                        |
>                        v
>             Position of sun/moon/stars
>                and sky colours
>                        |
>                        |
>                        v
>              Correctly rendered sky
>

The exception being that I don't use local time yet. I will add this later on, in
a separate class. The idea behind this is that you can only have one intstance of
a localtime class, but multlple instances of localtime in a single program. For
instance, in a hypothetical multiplayer sessionFlightGear, player one in Amsterdam
uses a different localtime then player b). in Sydney.

The  layout I have in mind looks something like the following:

Time:  all non-local time functions: hides all the nasty details of working
             with low-level time functions in a cross-platform environment.
             Only one instance allowed per program.(1)

LocalTime: A generic class for calculating local time, from longitude and UTC.
       |-------> EarthTime:   A more sophisticated mechanism, which makes
                                                      use of the timezone
mechanism
                                                      currently in FlightGear.


Timezone:   A database containing a description of all past and current timezone
                        rules. Currently already available in a somewhat crude
form.

While shuffling stuff around today, I made an interesting discovery: In
flightgear, we currently use two functions to obtain sidereal time. A precise
method and a fast method. I already noticed before that the precise method
appeared much shorter than the cheap method, so I decided, that while I was
tearing stuff apart, It would be interesting to benchmark both functions and see
how they performed. Much to my surprise, the precise method is about 3 times
faster than the cheap one. (About 30 million iterations in 30 seconds for the
precise method vs. about 10 million interations in 30 seconds for the cheap method
both tested on an Athlon 5000 MHz, running a 2.2.14 linux kernel). Inspection of
the profiling report, however revealedthat although the cheap method was indeed
somewhat faster in itself, it calls mkgm, which turned out to be relatively slow
and  take all  of the advantage away.

Based on this, I intend to scrap the cheap sidereal time estimation altogether,
because it will also yield a much cleaner code base.

>
>
> > Eventually, I'd like to develop some code that is also suitable for use in
> > stuff like a Space Flight simulator, and this would impose an additional
> > demand on the lib. My first choice in that case would be to include the
> > Astronomy and Time code in something like Curt's SimGear lib. As said, I'm
> > open to suggestion.
>
> Yes - me too!

>
>
> What I want to avoid at all costs is introducing more dependancies into
> games that use PLIB.  If Curt's new sky code is to be in some SSG-Utils
> library then it needs to depend only on SG/SSG and (possibly) other PLIB
> components.  I don't want people to have to download SimGear in order
> to get (say) Tux_AQFH to display stars/sun/moon.

Well, euhh... I already introduced a dependancy on SimGear, since I use simgear's
contants.h file.  This is only a working solution, however. Haven't really made my
mind up about this. The same goed for the Astronomy lib. Getting that one right
and making it usable across a wide range of purposes is extremely complicated. For
example, having planets in the correct position is overkill in an arcade game and
considered extreme by some people when it comes to FlightSims (sorry Steve :-)
:-)), but needed for stuff like planetarium programs and essential for something
like a space simulator. when it comes to the latter, differences in requirements
are huge as well. Whereas a 0.5 arc minute accurarcy could be tolarable for a
simple planetarium, you'd need an accuracy of at least a few kilometers when it
comes to writings space sims. In the last category, You'd also need code to render
planets, calculate graviational interactions, etc, etc,

Regards,
Durk

(1). Footnote: While thinking of it this morning, I realized that in some extreme
situation, one could write an intergalactic space flight simulation, using
spaceships that approach the speed of light. in that case clocks would go out of
sync, and one would need multiple instances of Time. However, waking up too early
this morning, and having a slight hangover, my mind refused to go in that
direction. So until it will, there's only one instance of class Time allowed.

Re: [Plib-devel] DXF load/save

[Bill W. <bil...@ch...>]

Yes, actually I saw Dave's messages about OBJ well after he had
committed the code; I had some other diversions, but I still need an OBJ
loader that does textures, so I will do it.  The only question is
whether I should just dump my version and add textures to Dave's loader,
or continue with mine.

Bill Weiland

Steve Baker wrote:
> 
> Dave McClurg wrote:
> 
> > I commited Wavefront OBJ import/export functions to PLIB/SSG
> > They only handle geometry right now
> > If someone can give me to a texture mapped OBJ model, i'll work on
> > adding the texture support
> 
> Bill Weiland <bil...@ch...> said that he was working on an SSG
> loader that would be ready "probably within the next few weeks"...dunno
> what happened to that.
> 
> Bill - are you listening?
>

Re: [Plib-devel] DXF load/save

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

Dave McClurg wrote:

> - The trivial alias/AC3D triangle import/export was omitted from
> the loader/writer list.

I can add that easily.
 
> - I got permission from the author of IVCON, John Burkardt, to use
> his code in PLIB under LGPL

Cool!
 
> - For the loaders, would the following be wise:
> 
>         if ( glIsEnabled ( GL_LIGHTING ) )
>            load normal array
>         else
>            load color array
> 
> That way, you only get the data you need.  Or are there some cases
> which need both?

You need them both under both circumstances:

  if lighting is enabled:

      You can have both per-vertex colours (using GL_COLOR_MATERIAL)
      and per-vertex normals.

  if lighting is disabled:

      You obviously need per-vertex colours - but you may also
      want something like sphere-mapped texturing which makes use
      of per-vertex normals to do cheesy environment mapping.

So, this is not a wise change.

> Or is there a different way to decide which is needed?
> In my game, everything will be prelit so I will leave lighting disabled
> and I don't need vertex normals.

Perhaps we need to add a 'hinting' mechanism for the loaders to tell them
about this kind of thing.
 
> - you can make a "really nice" skybox in 3DSMAX.
> i would prefer that over a skydome.

It depends a lot on the application.

Skyboxes really stink when you want the eyepoint to move over large
distances at high speed - or if you want things like wind-blown clouds.

Curt's offer of his skydome code comes from FlightGear which *needs*
a dome for the sky.  Obviously as an SSG-Util function, it would be
optional.  If you have something to offer to make good use of 3DSMAX
sky boxes - then I'd be happy to consider it.

> - Welcome back Steve and Happy St Patricks Day!  I hope everyone has
> planted their potatoes in the northern hemisphere.

I always plant my potatoes in the northern hemisphere - it's too far
to walk to get to the southern hemisphere.   :-)

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

Re: [Plib-devel] ssg sky

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

Steve Baker writes:
> > If you are interested I could send you some code.
>
> Yes please.

Ok, here's what I've got.  Feel free to hack it up however you like.
As long as I can reasonably accomplish the same sorts of things with
it, I'll commit to using it within flightgear.

Note, the only "FlightGear" dependency is that this uses the STL
"string" class so I pull in the fgfs "compiler.h" file which is our
attempt to hide a variety of platform differences.  If you made this
"char *" based, then you could eliminate that dependency.

Regards,

Curt.
--
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] ssg sky

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

"Curtis L. Olson" wrote:

> If you like, I'd be happy to move
> FlightGear's path generalization code to plib ... or I could
> contribute it as a starting point so you could "SteveBaker-ify" it.
> As long as we could still accomplish the same basic things with it,
> I'd be happy to use plib functionality for platform path independence.
> 
> I think this would definitely something that would fit well within the
> scope of plib.
> 
> If you are interested I could send you some code.

Yes please.

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

Re: [Plib-devel] I'm outta here.

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

"Curtis L. Olson" wrote:
> 
> Yes, the person posting the "rumor" also mentioned that he didn't
> understand why nvidia still says on their web page that they plan to
> use DRI ... who knows ... I'd love to hear more out of nvidia about
> their current plans, directions, and where they are at in the whole
> scheme of things.  I'd really like to get back to having a working 3d
> card real soon now.

The current detonator driver (Windos NT) changed my FGFS framerate from
20-30 to 2-3. Argh!

The only reason why I updated the driver was, that there was a cool
shadow example program on the nVidia web-page that I wanted to try...

CU,
Christian

Re: [Plib-devel] I'm outta here.

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

Christian Mayer writes:
> I'm not reading the 'unofficial' sites with the rumors, but the official
> nVidia Linux driver site
> (http://www.nvidia.com/Products.nsf/htmlmedia/software_drivers.html)
> says:
>
>   ... The upcoming XFree86 X server 4.0 will use the Direct
>   Rendering Infrastructure required to take full advantage of the
>   RIVA processors. ...
>
> This tells me that they'll use DRI. (Currently they aren't. But their
> current drivers crash with even the most simplistic OpenGl applications
> very badly)

Yes, the person posting the "rumor" also mentioned that he didn't
understand why nvidia still says on their web page that they plan to
use DRI ... who knows ... I'd love to hear more out of nvidia about
their current plans, directions, and where they are at in the whole
scheme of things.  I'd really like to get back to having a working 3d
card real soon now.

Curt.
--
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org