plib-devel

[Plib-devel] iv exports

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

Hi,


The iv exporter is in cvs.
I included it in ssg/Makefile.am and in ssg.dsp
I tested the Makefile.am only, but I expect win builds
should succeed with no problems.

I tested plib with ppe, and it works as expected.
If you encounter problems with saving .iv files,
let me know.

Also, I had to add a line to sggLoadAC.cxx because
when loading .ac files, I would get strange diffuse
values, with alpha set to 0. This would lead to
problems if I convert transparent materials from
ac to iv.
I don't think that alpha values 0.0 for diffuse
make any sense, as it would make the geometry
invisable.
The issue seemed to be caused by simply ignoring
diffuse values of ac materials.

    Bram

Re: [Plib-devel] iv exports

[Erik H. <er...@eh...>]

Bram Stolk wrote:

> Also, I had to add a line to sggLoadAC.cxx because
> when loading .ac files, I would get strange diffuse
> values, with alpha set to 0. This would lead to
> problems if I convert transparent materials from
> ac to iv.
> I don't think that alpha values 0.0 for diffuse
> make any sense, as it would make the geometry
> invisable.
> The issue seemed to be caused by simply ignoring
> diffuse values of ac materials.

Could you elaborate on that one a bit, since FlightGear depends heavily 
on plib's ac3d loader and I don't want to convert all models just 
because of this.

Erik

Re: [Plib-devel] iv exports

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

Erik Hofman wrote:

> Could you elaborate on that one a bit, since FlightGear depends heavily 
> on plib's ac3d loader and I don't want to convert all models just 
> because of this.

Ok,

When the AC loader loads a file, it will parse
ac materials.

 From these materials, ssgSimpleStates are constructed.
These ssgSimpleStates had their GL_SPECULAR, GL_EMISSION
values set, but not the GL_DIFFUSE.

This causes the un-intialized diffuse value of
0,0,0,0 being used in the ssgSimpleState node.
The un-initialized data may even be random, but
on my machine I observed 0,0,0,0 diffuse values
which make no sense.

That you dont see this weirdness normally, is probably
caused by the colour-per-vertex values that often overide
it.

Keeping un-initialized values in ssgSimpleStates is
bad anyway, because of PLIB's approach on vectors,
(which are float arrays, and not classes), plib
will not set a colour to a sane default.

The change I made in the loader is described here:
http://sourceforge.net/mailarchive/forum.php?thread_id=5647230&forum_id=7201

I dont think that it affects the loading of ac models by
flightgear in any negative way.
If it does, let me know, and I will investigate it further.
At least dog.ac and tuxedo.ac show no problems.

   Bram

> Erik

Re: [Plib-devel] iv exports

[Erik H. <er...@eh...>]

Bram Stolk wrote:
> Erik Hofman wrote:
> 
>> Could you elaborate on that one a bit, since FlightGear depends 
>> heavily on plib's ac3d loader and I don't want to convert all models 
>> just because of this.

> The change I made in the loader is described here:
> http://sourceforge.net/mailarchive/forum.php?thread_id=5647230&forum_id=7201 
> 
> I dont think that it affects the loading of ac models by
> flightgear in any negative way.
> If it does, let me know, and I will investigate it further.
> At least dog.ac and tuxedo.ac show no problems.

This doesn't look too involved, but we might end up with funny looking 
models. I'll do some tests with this change.

Thanks for the explanation.

Erik

Re: [Plib-devel] iv exports

[Erik H. <er...@eh...>]

Erik Hofman wrote:

> This doesn't look too involved, but we might end up with funny looking 
> models. I'll do some tests with this change.

If you don't know where to look at you probably won't even know the 
difference. But all in all it is a nice improvement, especially for 
billboarded objects.

Erik