plib-devel

[Plib-devel] Update on 3ds loader

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

I sat down and did some work on the 3ds loader this evening, and it works
better now. However, I have discovered some major weirdness that I'm not happy
about:

* One of the models Wolfram Kuss sent me, testquader.3ds, includes a texture
  called SNOO-CAT.BMP. I never got this texture to show in plib, which I hope
  is because the BMP image loader does something weird (I think Steve has said
  several times that the bmp format isn't to be trusted) - I can get it to work
  if I replace it with another texture (rgb, for example).

* A bit worse: The model chevy.3ds seems to miss some texture coordinates - at
  least my loader can't find them. There are some texture coordinates specified,
  but for some parts they just seem to be missing. Anyone who knows if there is
  another chunk than CHUNK_MAPLIST (0x4140) which is used by 3ds for storing
  map coordinates? Perhaps there is some intelligent default behaviour? For now,
  I just don't give any coords to ssg if they're missing, and display a warning.

The latest version of ssgLoad3ds.cxx can be downloaded from

  http://www.mdstud.chalmers.se/~md6pl/ssgLoad3ds.cxx

This version also includes the improvments made by Paolo Leoncini (a lot of
texture stuff), and all long integers are replaced by int. Even if not
perfect, the models come out looking ok, and it doesn't crash any longer (quite
an improvment, if you ask me :)

Regards,
Per Liedman

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

RE: [Plib-devel] proposal for PLIB 1.3 ssg load hints

[Dave M. <Dav...@dy...>]

Steve wrote:
> I wonder if it would be better to do this with a callback
> function though.  Under that scheme, if the application
> installs a 'Leaf node creation callback', then the loader
> will call the callback with the lists of vertices, colours,
> normals, etc - and the application would then create the
> node, populate the various fields (or not if it didn't
> want them) and return the address of the ssgEntity it
> finally decided to create back to the loader.
> 
yes. very flexible.
here is some code...

class ssgLoadLeafData
{
public:
  ssgLoadLeafData () ;
  ~ssgLoadLeafData () ;

  const char* name ;	   //node name
  GLenum gltype ;
  ssgVertexArray *vl ;
  ssgNormalArray *nl ;
  ssgTexCoordArray *tl ;
  ssgColourArray *cl ;
  ssgSimpleState *st ;
} ;

typedef ssgEntity* (*ssgLoadLeafCallback)( ssgLoadLeafData* data ) ;
static ssgLoadLeafCallback load_leaf_cb = default_load_leaf ;

the loader would do something like this:

	ssgLoadLeafData* data = new ssgLoadLeafData;
	//initialize leaf data from file data

	ssgEntity* ent = (*load_leaf_cb)( data ) ;
	if ( ent == NULL )
	   delete data ;
	else
	   current_branch->addKid ( ent ) ;

the default callback would be:

	ssgEntity* default_load_leaf ( ssgLoadLeafData* data )
	{
	  ssgVtxTable *vtab = new ssgVtxTable ( data->gltype,
	    data->vl, data->nl, data->tl, data->cl ) ;
	  if ( data->st )
	    vtab -> setState ( data->st ) ;
	  vtab -> setName ( data->name ) ;
	  return vtab ;
	}

-- Dave McClurg

Re: [Plib-devel] ROAM for plib

[Tom H. <to...@bi...>]

At 12:02 AM 4/6/2000 , you wrote:
>Sam Stickland wrote:
>
> > And then I'd like to add frame coherence to it would be would nice, and
> > doesn't sound that hard. (Basically instead of recalculating your triangle
> > mesh every frame you adjust the previous one to fit.
>
>Hmmm - but I'd still want FOV culling on the individual ROAM height grids
>(there could be many of them in an application like FlightGear where terrain
>is paged from disk).

This can be done.

>If a ROAM 'object' is entirely off-screen, then the ROAM algorithm would
>not be executed on that frame for that object.  I really think it's important
>to work that way.

The way you do this is you have each square section of terrain as an 
object. Each object contains two ROAM Bin-tri trees and pointers to its 4 
neighbors. After you've culled each object to the view frustum (AABB works 
great) you take a quick pass through the visible objects and check 
neighbors to see if they're visible. The pointers inside the bin-tri trees 
that point to neighbors would be set to null if neighbors are culled, and 
the pointer to the neighbor if not.

For split only engine this works great. For a frame coherent model what is 
usually done is the objects that are off the screen have their priority set 
to 0 so they are tessellated as little as possible. This is easier than 
trying to find all the neighbor pointers in the tree and set them to null. 
This adds a several hundred triangles that will be clipped by the API to 
the rendering of each frame. This is probably acceptable.

> > And at some point in the future I'd really like to adjust ROAM to work 
> in 3D
> > rather than just 2D so I can add stuff like caves and tunnels to the
> > landscape engine, but that's a far way off at the moment.
>
>That would be very cool.  Sounds tricky though.

Very much so :) If he has a cool plan for it, I'd love to hear it (although 
the algorithms list is probably a better place for it).

>If each ROAM 'object' is independent though, you could build things like
>caves by having a height grid for the floor, another (inverted) one for
>the ceiling and a third for the surface of the ground above the roof
>of the cave.

The problem is defining how the ceiling and the floor come together. I 
don't see how two height fields opposing each other can be used to make 
convincing walls in a cave, but I guess its better than nothing :) If I was 
to go with a full 3D scene I would leave height fields behind and go with 
something else (Beziers with displacement maps perhaps).

>That's nowhere near as nice as a full 3D implementation - but it certainly
>makes caves and overhangs do-able with the present algorithm.

It seems like the area where the two height fields come together would look 
"bad".

Tom

R: [Plib-devel] Importers/Exporters

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

So I assume Per will merge his and my modifs to the 3DS loader for 1.2. =
I'm anyway available to send my version of this source to a good-will =
integrator (Steve?), since I'm not yet familiar with CVS repository =
concepts.
When we will all be quiter after release 1.2 I would be thankful to =
anyone could explain about it, or where to get necessary startup info.

-----Messaggio originale-----
Da:	Per Liedman [SMTP:li...@ho...]
Inviato:	gioved=EC 6 aprile 2000 13.16
A:	pli...@li...
Oggetto:	Re: [Plib-devel] Importers/Exporters

Steve Baker wrote:
> Per Liedman wrote:
> > Unfortunately, this will take some effort to reorganize, so I'm not =
really sure
> > when I get it ready (I just have one hour or two to work on it each =
day), but
> > hopefully within a week. That might be too late for the 1.2 release, =
though.
>=20
> I think the 3DS loader is sufficiently important that we should wait =
for these
> fixes before declaring 1.2 ready.   The alternatives are either:
>=20
> * Release a 1.2 with a known-broken 3DS loader (that doesn't fit my
>   definition of a 'stable' release).
>=20
> * Remove the 3DS loader from the 1.2 release - and make loading 3DS
>   files be a 1.3 feature - that won't be stable until 1.4.
>=20
> I don't think either of those are acceptable...so we should hold up =
1.2.

Ok, I'll work as fast as I can. It seems I should get some free time
this evening.

Regards,
Per

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Per Liedman                                      =20
md...@md...
Nilssonsberg 7                      =20
http://www.mdstud.chalmers.se/~md6pl/
411 43 G=F6teborg                               tel: 031-825659 /
0705-520455
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


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

Re: [Plib-devel] Importers/Exporters

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

Steve Baker wrote:
> Per Liedman wrote:
> > Unfortunately, this will take some effort to reorganize, so I'm not really sure
> > when I get it ready (I just have one hour or two to work on it each day), but
> > hopefully within a week. That might be too late for the 1.2 release, though.
> 
> I think the 3DS loader is sufficiently important that we should wait for these
> fixes before declaring 1.2 ready.   The alternatives are either:
> 
> * Release a 1.2 with a known-broken 3DS loader (that doesn't fit my
>   definition of a 'stable' release).
> 
> * Remove the 3DS loader from the 1.2 release - and make loading 3DS
>   files be a 1.3 feature - that won't be stable until 1.4.
> 
> I don't think either of those are acceptable...so we should hold up 1.2.

Ok, I'll work as fast as I can. It seems I should get some free time
this evening.

Regards,
Per

-- 
===========================================================================
Per Liedman                                       
md...@md...
Nilssonsberg 7                       
http://www.mdstud.chalmers.se/~md6pl/
411 43 Göteborg                               tel: 031-825659 /
0705-520455
===========================================================================

Re: [Plib-devel] error message routines

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

> Dave McClurg wrote:
> 
> Here is the revised spec based on Steve's comments:

Thanks.  That seems much better.

> enum xxxSeverity
> {
>   XXX_DEBUG,    // Messages that can safely be ignored.
>   XXX_WARNING,  // Messages that are important.
>   XXX_FATAL,    // Errors that we cannot recover from.
> } ;
> 
> void xxxInit ( void ) ; //for now, just calls xxxClearError()
> 
> void xxxSetError ( int severity, const char *fmt, ... ) ;
> char* xxxGetError ( void ) ;
> void xxxClearError ( void ) ;
> 
> typedef void (*xxxErrorCallback)( char* ) ;
> xxxErrorCallback xxxGetErrorCallback ( void ) ;
> void xxxSetErrorCallback ( xxxErrorCallback cb ) ;
> 
> -----
> 
> The default error callback will print the
> message to stderr.  if ( severity == XXX_FATAL )
> should the default callback exit(1) the app?

Since we say that these are unrecoverable, we certainly
need to terminate the program after the error callback
has been called.

It should probably abort() to generate a core file...
but to a degree it doesn't matter what we do since
the application can clearly override the default
behavior by either calling exit(1) or abort(TRUE)
in his own error callback.

 
> This will be something general to all of PLIB -
> including PUI, SL, etc.  As a general library,
> the application might like to handle it's own
> errors the same way.

Yes.
 
> What should the new library be called (xxx)?
> Could we later add some endian support code,
> a plib version string, and a couple basic types?
> If so, a more general name than err would be
> appropriate.  How about...
> 
>         ul - utility library
> 
> Note: This adds a dependency to all the other
> PLIB libraries.

That all seems pretty reasonable.

There are a bunch of routines that could usefully
be placed there.

> Should I proceed?

Yes - if we are agreed that we want this in 1.2.

The main problem with this is that we'll cause
applications to have to amend their linker
command to include '-lplibul'.

That says to me that if we want this, we should
put out a final PLIB 1.1.xx release for testing
before 1.2.0 becomes the stable standard.

One way to avoid that is to make those few
simple routines fit into a header file as
'inline's - then there is no change to the
linker requirements in 1.2 - and we can
turn it into a fullscale library in 1.3.

Since none of those routines is likely to
be more than one or two lines, and existing
applications would continue to work without
including <plib/ul.h> - this would be more
acceptable to application authors I guess.

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

Re: [Plib-devel] proposal for PLIB 1.3 ssg load hints

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

> Dave McClurg wrote:
> 
> Currently, when you load something in SSG there is no
> way to control what gets loaded.  Usually, that is
> ok, but if you want a small memory footprint and
> don't have an easy way to cleanup the models, I
> propose adding load hint flags:
> 
> enum ssgLoadHintFlags
> {
>   SSG_LOAD_TEXTURES = (1<<0),  // texture images and coordinates
>   SSG_LOAD_VNORMALS = (1<<1),  // vertex normals
>   SSG_LOAD_VCOLOURS = (1<<2),  // vertex colours
>   SSG_LOAD_ANIMATION = (1<<3), // transform and mesh animation
>   SSG_LOAD_EVERYTHING = ((1<<15)-1),
>   SSG_LOAD_NOTHING = 0,
> } ;
> 
> void ssgLoadHint ( int hint_flags ) ;
> 
> Of course, this won't happen until PLIB 1.3 but
> i just wanted to throw the idea out for comment.

Yes - I can see why some people might want this.

I wonder if it would be better to do this with a callback
function though.  Under that scheme, if the application
installs a 'Leaf node creation callback', then the loader
will call the callback with the lists of vertices, colours,
normals, etc - and the application would then create the
node, populate the various fields (or not if it didn't
want them) and return the address of the ssgEntity it
finally decided to create back to the loader.

If the user does not define a leaf node creation callback
then the loader could simply create a default node type
containing all the data - needed in order not to break
existing applications.

That would have several advantages:

1) We allow the callback node to do this stuff
   conditionally (eg if you wanted only leaf nodes
   containing Purple polygons have their texture
   coordinates removed).

2) It would also solve a related problem - should
   the loader create an ssgVtxTable or the up-coming
   ssgCVA leaf node type?  Should the loader demand
   that a display list be created?  ...etc.

3) It would allow for new loader constraints to be
   added in the future without having to go in and
   change all of the half dozen loaders that are
   being written.

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

Re: [Plib-devel] ROAM for plib

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

Sam Stickland wrote:

> And then I'd like to add frame coherence to it would be would nice, and
> doesn't sound that hard. (Basically instead of recalculating your triangle
> mesh every frame you adjust the previous one to fit.

Hmmm - but I'd still want FOV culling on the individual ROAM height grids
(there could be many of them in an application like FlightGear where terrain
is paged from disk).

If a ROAM 'object' is entirely off-screen, then the ROAM algorithm would
not be executed on that frame for that object.  I really think it's important
to work that way.

> And at some point in the future I'd really like to adjust ROAM to work in 3D
> rather than just 2D so I can add stuff like caves and tunnels to the
> landscape engine, but that's a far way off at the moment.

That would be very cool.  Sounds tricky though.

If each ROAM 'object' is independent though, you could build things like
caves by having a height grid for the floor, another (inverted) one for
the ceiling and a third for the surface of the ground above the roof
of the cave.

That's nowhere near as nice as a full 3D implementation - but it certainly
makes caves and overhangs do-able with the present algorithm.

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

Re: [Plib-devel] Importers/Exporters

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

Per Liedman wrote:
> 
> On Mon, 20 Mar 2000, Wolfram Kuss wrote:
> > 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.
> 
> It seems that I have made an assumption about the ordering of the chunks in the
> 3ds file that not all 3ds models follow, which makes Wolframs models crash
> the loader - the texture coords get defined after the ssgVtxTable, so I'm
> copying from a NULL-pointer :-(
> 
> Unfortunately, this will take some effort to reorganize, so I'm not really sure
> when I get it ready (I just have one hour or two to work on it each day), but
> hopefully within a week. That might be too late for the 1.2 release, though.

I think the 3DS loader is sufficiently important that we should wait for these
fixes before declaring 1.2 ready.   The alternatives are either:

* Release a 1.2 with a known-broken 3DS loader (that doesn't fit my
  definition of a 'stable' release).

* Remove the 3DS loader from the 1.2 release - and make loading 3DS
  files be a 1.3 feature - that won't be stable until 1.4.

I don't think either of those are acceptable...so we should hold up 1.2.

It would be possible to launch 1.3's CVS area while we are waiting for
1.1 to metamorphose into 1.2...Mesa did that for example.

I'm reluctant to do that though...it causes a LOT of confusion.

The reason I'd hoped to get 1.2 done soon was to get it onto SuSE 6.4 - but
I fear that we are already too late for that.

> Paolo Leoncini has also made some modifications to the loader that I think
> should be included - at least some improvement over the current loader (better
> texture support). Perhaps Paolo could send the files directly to Steve for
> incorporation?

OK - would it be better just to grant CVS access to people working this
stuff though.  I'm so busy right now - that it'll be a while before I
can catch up with some of these new changes.

-- 
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:
> 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.

It seems that I have made an assumption about the ordering of the chunks in the
3ds file that not all 3ds models follow, which makes Wolframs models crash
the loader - the texture coords get defined after the ssgVtxTable, so I'm
copying from a NULL-pointer :-(

Unfortunately, this will take some effort to reorganize, so I'm not really sure
when I get it ready (I just have one hour or two to work on it each day), but
hopefully within a week. That might be too late for the 1.2 release, though.

Paolo Leoncini has also made some modifications to the loader that I think
should be included - at least some improvement over the current loader (better
texture support). Perhaps Paolo could send the files directly to Steve for
incorporation?

Regards,
Per Liedman

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

Re: [Plib-devel] ROAM for plib

[Sam S. <sa...@fp...>]

Hi,

Steve Baker wrote:

> I don't think it would be inappropriate to write a ROAM node for SSG.

Cool.

> I agree that it seems like a rather higher level feature than SSG would
> normally implement - but it's a feature that would be VERY hard to
implement
> using only the existing SSG API - and it's popular enough to warrant being
> something that SSG should not prohibit.
>
> I havn't played much with ROAM - but the general wisdom seems to be
> that implementing the entire algorithm is counter-productive - something
> about one of the optimisations that - erm - pessimises.

Yes.  I think you're refering to that fact that the original ROAM paper uses
a metric based on nested world- space bounds to work out the visible error
in the grid.  The gamasutra implementation uses a variance tree to do this
instead (as does Seumas McNally's Treadmarks's engine), which is a LOT
quicker :)

You can set up the visible error you wish to allow in different ways to do
some clever stuff.  The default implementation increases the allowed visible
error with distance (so less triangles get drawn the futher away thay are)
to implement the standard LOD for example.

But you could have some landscape features always drawn with a high LOD if
you wish - although to do this from one API will require a fair bit of
tinkering with gamasutra's ROAM engine.  I was thinking of having a second
height-map style thing that would specify error tolerance for this sort of
stuff (but that can come in the future :) ).

> Anyway - I think it's not a bad idea - but to steal an acronym from the
> PPE group:  NIV12.  (Not In Version 1.2)

Heh.. Certainly not... I do have to have a life as well.  This'll take a
week or so to do I think (including the time needed to adjust the gamasutra
implementation to use fan-strips rather than drawing lots of individual
triangles.

And then I'd like to add frame coherence to it would be would nice, and
doesn't sound that hard. (Basically instead of recalculating your triangle
mesh every frame you adjust the previous one to fit.  If it's taking to long
to do you just draw the mesh anyway - this way when there's a lot of other
stuff getting drawn (i.e.. you're in a fire-fight), the LOD of the landscape
will degrade fairly gracefully).

And at some point in the future I'd really like to adjust ROAM to work in 3D
rather than just 2D so I can add stuff like caves and tunnels to the
landscape engine, but that's a far way off at the moment.

Sam

[Plib-devel] proposal for PLIB 1.3 ssg load hints

[Dave M. <Dav...@dy...>]

Currently, when you load something in SSG there is no
way to control what gets loaded.  Usually, that is
ok, but if you want a small memory footprint and
don't have an easy way to cleanup the models, I
propose adding load hint flags:

enum ssgLoadHintFlags
{
  SSG_LOAD_TEXTURES = (1<<0),  // texture images and coordinates
  SSG_LOAD_VNORMALS = (1<<1),  // vertex normals
  SSG_LOAD_VCOLOURS = (1<<2),  // vertex colours
  SSG_LOAD_ANIMATION = (1<<3), // transform and mesh animation
  SSG_LOAD_EVERYTHING = ((1<<15)-1),
  SSG_LOAD_NOTHING = 0,
} ;

void ssgLoadHint ( int hint_flags ) ;

Of course, this won't happen until PLIB 1.3 but
i just wanted to throw the idea out for comment.

-- Dave McClurg
mailto:dav...@dy...         http://www.dynamix.com
mailto:da...@po... (home)            http://www.pond.net/~davem 

[Plib-devel] error message routines

[Dave M. <Dav...@dy...>]

Here is the revised spec based on Steve's comments:

----

enum xxxSeverity
{
  XXX_DEBUG,	// Messages that can safely be ignored.
  XXX_WARNING,	// Messages that are important.
  XXX_FATAL,	// Errors that we cannot recover from.
} ;

void xxxInit ( void ) ; //for now, just calls xxxClearError()

void xxxSetError ( int severity, const char *fmt, ... ) ;
char* xxxGetError ( void ) ;
void xxxClearError ( void ) ;

typedef void (*xxxErrorCallback)( char* ) ;
xxxErrorCallback xxxGetErrorCallback ( void ) ;
void xxxSetErrorCallback ( xxxErrorCallback cb ) ;

-----

The default error callback will print the
message to stderr.  if ( severity == XXX_FATAL )
should the default callback exit(1) the app?

This will be something general to all of PLIB -
including PUI, SL, etc.  As a general library,
the application might like to handle it's own
errors the same way.

What should the new library be called (xxx)?
Could we later add some endian support code,
a plib version string, and a couple basic types?
If so, a more general name than err would be
appropriate.  How about...

	ul - utility library

Note: This adds a dependency to all the other
PLIB libraries.

Should I proceed?

-- Dave McClurg

Re: [Plib-devel] ssg error message routines

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

Dave McClurg wrote:

> PPE should probably do something like this.

...so I guess it shouldn't be an SSG function - but
something general to all of PLIB - including PUI, SL,
etc.  As a general library, the application might like
to handle it's own errors the same way.

> To handle multiple error messages, the application
> could redirect stderr to a file or I could echo errors
> to a file in ssgSetError().  which do you prefer?

Using a callback into the application would solve the
problem of multiple errors.
 
(That's how Performer handles it).

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

Re: [Plib-devel] texture support for ssgLoadOBJ

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

> Dave McClurg wrote:

> while i was at it, i added some simple error message routines:
> 
>         void ssgSetError(const char *fmt, ...);
>         char* ssgGetError(void);
>         void ssgClearError(void);

There should probably be a 'severity' indicator:

   SSG_DEBUG   -- Messages that can safely be ignored.
   SSG_WARNING -- Messages that are important.
   SSG_FATAL   -- Errors that SSG cannot recover from.

It would be nice for the application to be able to register
a callback that SSG will call when an error occours - have
it default to something that just dumps the message to stderr.

> I'd like to apply these error message routines to my loaders
> and perhaps all of SSG unless there are objections.

Nope no objections - we need something along these lines.

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

Re: [Plib-devel] texture support for ssgLoadOBJ

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

Wolfram Kuss wrote:
> 
> Dave wrote:
> 
> >
> >> - I had a texture with a size that is not a power of two.
> >> plib complained (map is not a power-of-two in size)
> >> and exits the program!
> >i'll track that down if you want to send me the texture
> 
> Lets first decide what we want :-).
> I think most or all graphics cards want to have texture-sizes
> that are a power of two. So, internally, we should only have such
> textures.

More than that - it is a REQUIREMENT of OpenGL that maps have
power of two sizes.

Before we started to use SSG for PPE and stuff like that, it didn't
matter that it exited when something as serious as this happened.
The developer of a game would see his error and fix it.  No big
deal.

However, now that SSG is used in things like the PPE modeller, it's
important that we can survive without crashing - and yet still report
the seriousness of the problem to the application.

> I see two ways to deal with this:
> - Dont load wrong textures, give an error-message, go on loading
> everything else.

Exactly.

> - Resample the texture when loading. This, of course, slows loading
> the texture. Therefore, authors (of games or whatever) should resample
> their textures once in a paint-program anyway. If we go this way,
> I want a dialog saying "this is not a nice texture, if you want to go
> on using it or even distribute it, resample it".

I don't think that's a good plan.  People will ignore the error if SSG
kludges a fix - and the texture will just look bad.

Replace the broken texture with a magenta and green chequerboard or
something.  People learn to recognise this as the 'broken texture'
symptom.

> It is surprising how uniformed people can be, even if they create
> textures professionally. For a long time, we had monochrome textures
> with a size of, for example 118x112 pixels :-(.
> So, our program was used with the hand brake on :-(. (German idiom,
> translated into English. I dont know whether there is an English one).

Yep.  OpenGL implementations are SUPPOSED to ignore non-power of two
maps...not all of them do.

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

Re: [Plib-devel] ROAM for plib

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

Sam Stickland wrote:

> There's a good article on www.gamasutra.com on Adaptive LOD terrian using
> ROAM.  Up until now my program has been using a naff quadtree implementation
> written by me, and I'm convinced enough to move to this implementation.
> 
> I'm almost certainly going to move my project over to SSG (since it doesn't
> use any Scene graph at all at the moment).
> 
> So I'm thinking that I could rework ROAM landscape's into the SSG API as a
> couple of extra classes.  Would this be useful, or do you want this sort of
> extra complexity kept out of it?

I don't think it would be inappropriate to write a ROAM node for SSG.

I agree that it seems like a rather higher level feature than SSG would
normally implement - but it's a feature that would be VERY hard to implement
using only the existing SSG API - and it's popular enough to warrant being
something that SSG should not prohibit.

I havn't played much with ROAM - but the general wisdom seems to be
that implementing the entire algorithm is counter-productive - something
about one of the optimisations that - erm - pessimises.

Anyway - I think it's not a bad idea - but to steal an acronym from the
PPE group:  NIV12.  (Not In Version 1.2)

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

Re: Vertex submission (was Re: [Plib-devel] Re: 3DNow! acceleration)

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

Sam Stickland wrote:

> To get the best speed out of CVA's won't it need some adjustment to the
> scene graph traversal?  Say we had this structure:
> 
>              Transform Node                    Transform Node
>                            |                                            |
>                            +------- CVA Node ---------+
> 
> Then you'd want to lock the arrarys, draw the CVA Node in both positions and
> then unlock it - rather than locking it twice.

Well, only if the two references to that node were at the same position
in the scene.
 
> I guess this might start to get a little to complex, particulary if you
> start to factor in different states.

Yep. 


  The CVA will only be re-usable within a frame if it's drawn
more than once at exactly the same place in the scene.  Hence, you
couldn't use it to draw twenty identical buildings in a scene - but
you could use it to draw the building with one texture - and then
again at the precise same location with alpha blending and a second
texture.

Hence, we would want that ability to simulate more complex rendering
than the underlying OpenGL can manage. In a word: Multipass.

I think this would be best implemented by creating a new kind of
ssgState that contained multiple internal ssgState nodes (much
like the current ssgStateSelector node) - but with the semantics
being that the ssgLeaf that uses it would render multiple times -
each using a different sub-state.  For regular ssgVtxList nodes,
that wouldn't be too efficient - but for CVA nodes, it would be
fast.

This would look really nice to the user - just create a 'multistate',
to describe whatever 'look' you want your geometry to have - and
whatever you connect it to get's rendered using multipass automatically.

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

Re: [Plib-devel] Double-sided material fix to 3DS loader for 1.2

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

Per Liedman wrote:

> By the way, I use a modified version of the tux_example to test the 3ds-loader,
> and have stumbled across something I think is sort of odd. If I load one of the
> models supplied by Wolfram Kuss (550.3ds), it looks what I think it should look
> like (a large building), but if I also load the pedestal model from the
> original tux_example, the whole building turns white (no lighting or anything)!
> Any suggestions to what might cause this? (The loader does not use
> GL_COLOR_MATERIAL, if that is of any interest.)

One thing that can cause that sort of thing is enabling texture but not
providing texture coordinates - or enabling lighting and not providing
normals...that kind of thing.

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

[Plib-devel] ssg error message routines

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

more info on the error routines I added:

	void ssgSetError ( const char* fmt, ... ) ;
	char* ssgGetError ( void ) ;
	void ssgClearError ( void ) ;

Here are some examples of how an application might
handle errors.  If ErrorBox() shows a message to the
user then to handle a fatal load error:

	ent = ssgLoad ( fname ) ;
	if ( ent == NULL ) {
	   ErrorBox ( ssgGetError() ) ;
	}

To handle all load error returns:

	ssgClearError();
	ent = ssgLoad ( fname ) ;
	if ( ent == NULL ) {
	   //fatal error
	   ErrorBox ( ssgGetError() ) ;
	}
	else if ( strcmp(ssgGetError(), "") != 0 ) {
	   //non-fatal errors ... still returned something
	   ErrorBox ( ssgGetError() ) ;
      }

PPE should probably do something like this.

This is how it is done in SDL (Simple Direct Media Layer)
and I would like to do it the same in SSG
unless there are objections.

To handle multiple error messages, the application
could redirect stderr to a file or I could echo errors
to a file in ssgSetError().  which do you prefer?

-- Dave McClurg

RE: [Plib-devel] texture support for ssgLoadOBJ

[Dave M. <Dav...@dy...>]

> >> - I had a texture with a size that is not a power of two.
> >> plib complained (map is not a power-of-two in size)
> >> and exits the program!
> 
> - Dont load wrong textures, give an error-message, go on loading
> everything else.
>
done.  i used Steve's loadDummyTexture() in the event that
make_mip_maps() finds non power-of-two sizes.

while i was at it, i added some simple error message routines:

	void ssgSetError(const char *fmt, ...);
	char* ssgGetError(void);
	void ssgClearError(void);

this is similar to what SDL uses.  SetError fprintfs to stderr
and stores the message in a buffer that can be retreived with
GetError.  SetError could also echo to a stderr.txt file if
we want to capture multiple error messages.

I'd like to apply these error message routines to my loaders
and perhaps all of SSG unless there are objections.

-- Dave McClurg

Re: [Plib-devel] texture support for ssgLoadOBJ

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

Dave wrote:

>
>> - I had a texture with a size that is not a power of two.
>> plib complained (map is not a power-of-two in size)
>> and exits the program!
>i'll track that down if you want to send me the texture

Lets first decide what we want :-).
I think most or all graphics cards want to have texture-sizes
that are a power of two. So, internally, we should only have such
textures.
I see two ways to deal with this:
- Dont load wrong textures, give an error-message, go on loading
everything else.
- Resample the texture when loading. This, of course, slows loading
the texture. Therefore, authors (of games or whatever) should resample
their textures once in a paint-program anyway. If we go this way,
I want a dialog saying "this is not a nice texture, if you want to go
on using it or even distribute it, resample it".
It is surprising how uniformed people can be, even if they create
textures professionally. For a long time, we had monochrome textures
with a size of, for example 118x112 pixels :-(.
So, our program was used with the hand brake on :-(. (German idiom,
translated into English. I dont know whether there is an English one).

Bye bye,
Wolfram Kuss.

RE: [Plib-devel] Double-sided material fix to 3DS loader for

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

On Tue, 04 Apr 2000, Dave McClurg wrote:
> in tux_example, if you load something without state then
> you should get current color as last set by glColor since
> lighting is disabled.  current color is inconsistant because
> it depends on the last call to glColor.
> 
> if you have a simple test case that demonstrates the bug,
> let's have it because we really need to nail this down.

Just replace the tux model with the model 550.3ds supplied by Wolfram Kuss.
Remove the ssgFlatten/ssgStripify (they somehow seem to break my models, not
sure why). If you load the pedestal, the 550 model turns all white (no
shading), without the pedestal it looks nice (many colours, shaded).

I don't say this has to do with GL_COLOR_MATERIAL, I just don't really have a
clue what the cause might be?!

Anyway, in this case, it doesn't have to do with states not being defined - the
loader creates states and works (at least under some conditions :-) Perhaps I
have forgotten to enable/disable something that has an ok default setting, but
is changed by the pedestal model?

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

RE: [Plib-devel] Double-sided material fix to 3DS loader for

[Dave M. <Dav...@dy...>]

> > Per Liedman writes:
> > > By the way, I use a modified version of the tux_example 
> to test the
> > > 3ds-loader, and have stumbled across something I think is sort of
> > > odd. If I load one of the models supplied by Wolfram Kuss 
> (550.3ds),
> > > it looks what I think it should look like (a large 
> building), but if
> > > I also load the pedestal model from the original tux_example, the
> > > whole building turns white (no lighting or anything)!  Any
> > > suggestions to what might cause this? (The loader does not use
> > > GL_COLOR_MATERIAL, if that is of any interest.)
> 
> Curtis L. Olson writes:
> > I've noticed similar behavior with ssg ... I've never been 
> able to get
> > an ssgSimpleState to work consistantly if it doesn't use
> > gl_color_material and if it doesn't have a texture.  I've seen this
> > enough times to speculate that either:
> > 
> > a) there is some state changing bug in ssg
> > 
> > b) there is some non-obvious thing that needs to get done 
> to make this
> > work right
> 
> Just in case what I wrote was confusing.  If I'm trying to create a
> simplestate that sets material properties without enabling
> gl_color_material and at the same time doesn't have a texture applied,
> then I see really inconsistant results ... it will work at times and
> not work at times depending on view direction and position.  Work
> being defined as I get what I think I should get, and not-work being
> defined as I get an all white shaded surface.  My guess is that as
> various objects are culled or drawn, this has a side effect on the
> objects in question so that sometimes they are rendered correctly, and
> sometimes not.
> 

in tux_example, if you load something without state then
you should get current color as last set by glColor since
lighting is disabled.  current color is inconsistant because
it depends on the last call to glColor.

if you have a simple test case that demonstrates the bug,
let's have it because we really need to nail this down.

alternatively, SSG could use a "default simplestate" or
just initialize glColor when it renders.  Anyone want
to define a "default simplestate"?

--
Dave McClurg

RE: [Plib-devel] ROAM for plib

[Dave M. <Dav...@dy...>]

> So I'm thinking that I could rework ROAM landscape's into the 
> SSG API as a
> couple of extra classes.  Would this be useful, or do you 
> want this sort of
> extra complexity kept out of it?
> 
probably belongs a level higher in PLIB-Glut/SimGear

adaptive LOD is good for an action/explore games
but for a racing game you want LOD controlled
by the path you take through the terrain.

--
Dave McClurg