Thread: [Plib-devel] 3DS loader bug? [Fwd: Porting loaders to SGL]
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Steve B. <sjb...@ai...> - 2000-07-11 05:07:57
|
Scott McMillan wrote:
> 2) I may have found a bug. Not knowing the 3ds format at all, I
> cannot be sure. It involves the parsing texture scale and offset
> parameters starting at line 343 (of PLIB version 1.2.0). Shouldn't
> parse_uscale() stick the value into element 0 of the texture_scale?
>
> static int parse_uscale( char **p, unsigned int length )
> {
> texture_scale[ num_materials - 1 ][1] = get((float*)*p);
> // ^^^
> // 0?
> return PARSE_OK;
> }
>
> static int parse_vscale( char **p, unsigned int length )
> {
> texture_scale[ num_materials - 1 ][0] = get((float*)*p);
> // ^^^
> // 1?
> return PARSE_OK;
> }
>
> static int parse_uoffst( char **p, unsigned int length )
> {
> texture_offst[ num_materials - 1 ][0] = get((float*)*p);
> return PARSE_OK;
> }
>
> static int parse_voffst( char **p, unsigned int length )
> {
> texture_offst[ num_materials - 1 ][1] = get((float*)*p);
> return PARSE_OK;
> }
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Paolo L. <p.l...@ci...> - 2000-07-11 08:57:53
|
> Scott McMillan wrote:
>
> > 2) I may have found a bug. Not knowing the 3ds format at all, I
> > cannot be sure. It involves the parsing texture scale and offset
> > parameters starting at line 343 (of PLIB version 1.2.0). Shouldn't
> > parse_uscale() stick the value into element 0 of the texture_scale?
> >
> > static int parse_uscale( char **p, unsigned int length )
> > {
> > texture_scale[ num_materials - 1 ][1] = get((float*)*p);
> > // ^^^
> > // 0?
> > return PARSE_OK;
> > }
> >
> > static int parse_vscale( char **p, unsigned int length )
> > {
> > texture_scale[ num_materials - 1 ][0] = get((float*)*p);
> > // ^^^
> > // 1?
> > return PARSE_OK;
> > }
> >
> > static int parse_uoffst( char **p, unsigned int length )
> > {
> > texture_offst[ num_materials - 1 ][0] = get((float*)*p);
> > return PARSE_OK;
> > }
> >
> > static int parse_voffst( char **p, unsigned int length )
> > {
> > texture_offst[ num_materials - 1 ][1] = get((float*)*p);
> > return PARSE_OK;
> > }
I modified Per Liedman's 3DS loader in this way since 3DS files exported by
3DStudio Max (3.0) present such u-v scale swap (coming from the
repetition/tiling param). Have you tried with any datafile? I did it with
textured 3DS'es produced by Max, Sim Rational Reducer (very good!), and
Rhino3D - it seems to work. But I can't exclude exceptions to this
experimental rule.
Greetings -
----------------------------------------------------------------------------
-
Paolo Leoncini phone: +39 (0823) 623134
Scientific Visualization Group fax: +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy www.cira.it/research/vis
|
|
From: Scott M. <mcm...@ca...> - 2000-07-11 16:03:43
|
I am not sure what you are saying. Are you saying the scale is
swapped but the offset is not? In other words, is the code as
written in version 1.2.0 correct:
parse_uscale goes to element [1]
but parse_uoffst goes to element [0]
etc....? I personally don't have the capability of generating
3ds models to test this aspect.
Paolo Leoncini wrote:
>
> > Scott McMillan wrote:
> >
> > > 2) I may have found a bug. Not knowing the 3ds format at all, I
> > > cannot be sure. It involves the parsing texture scale and offset
> > > parameters starting at line 343 (of PLIB version 1.2.0). Shouldn't
> > > parse_uscale() stick the value into element 0 of the texture_scale?
> > >
> > > static int parse_uscale( char **p, unsigned int length )
> > > {
> > > texture_scale[ num_materials - 1 ][1] = get((float*)*p);
> > > // ^^^
> > > // 0?
> > > return PARSE_OK;
> > > }
> > >
> > > static int parse_vscale( char **p, unsigned int length )
> > > {
> > > texture_scale[ num_materials - 1 ][0] = get((float*)*p);
> > > // ^^^
> > > // 1?
> > > return PARSE_OK;
> > > }
> > >
> > > static int parse_uoffst( char **p, unsigned int length )
> > > {
> > > texture_offst[ num_materials - 1 ][0] = get((float*)*p);
> > > return PARSE_OK;
> > > }
> > >
> > > static int parse_voffst( char **p, unsigned int length )
> > > {
> > > texture_offst[ num_materials - 1 ][1] = get((float*)*p);
> > > return PARSE_OK;
> > > }
>
> I modified Per Liedman's 3DS loader in this way since 3DS files exported by
> 3DStudio Max (3.0) present such u-v scale swap (coming from the
> repetition/tiling param). Have you tried with any datafile? I did it with
> textured 3DS'es produced by Max, Sim Rational Reducer (very good!), and
> Rhino3D - it seems to work. But I can't exclude exceptions to this
> experimental rule.
--
Scott McMillan mailto:mcm...@ca...
Cambridge Research Associates http://www.cambridge.com
1430 Spring Hill Road, Ste. 200 Voice: (703) 790-0505 x7235
McLean, VA 22102 Fax: (703) 790-0370
|
|
From: Paolo L. <p.l...@ci...> - 2000-07-12 13:08:31
|
Scott McMillan wrote:
>
> I am not sure what you are saying. Are you saying the scale is
> swapped but the offset is not? In other words, is the code as
> written in version 1.2.0 correct:
>
> parse_uscale goes to element [1]
> but parse_uoffst goes to element [0]
>
> etc....? I personally don't have the capability of generating
> 3ds models to test this aspect.
>
Premise:
Max (like, perhaps, the older 3DStudio) conceptually separates UVW Mapping
(per object) and transformations on the texture image (per material). The
former implicitly modifies object texture coordinates, while the latter goes
as explicit uv scale and offset values among the material params - these are
the values we are talking about. In particular, scale is the Tiling value
within the Max Material Editor user interface (the default 1.0 value is not
written in the 3DS file, so the need of an initialization at the end of the
file!).
Back to our problem, I *never* had occasion to apply an offset to a
(material) texture, yet normally put offset to objects' UVW mapping.
Just now I did a test on texture uv-offset and experienced that the right
Max -> SSG mapping can be obtained by negating the u-offset, i.e. in the
source
static int parse_uoffst( char **p, unsigned int length )
{
texture_offst[ num_materials - 1 ][0] = -get((float*)*p); <<== !
return PARSE_OK;
}
static int parse_voffst( char **p, unsigned int length )
{
texture_offst[ num_materials - 1 ][1] = get((float*)*p);
return PARSE_OK;
}
so, for answering to your question, as to my datasets:
- u-scale goes to index 1
- u-offset goes to index 0, but with the opposite sign.
Scale/offset on object UV-mapping does correctly work since is directly
managed by Max.
I'll do some further tests on this, but I would like to hear some other
experience on this. Per and I should then converge to a new version of the
3DS loader.
----------------------------------------------------------------------------
-
Paolo Leoncini phone: +39 (0823) 623134
Scientific Visualization Group fax: +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy www.cira.it/research/vis
|
|
From: Steve B. <sjb...@ai...> - 2000-07-12 00:37:40
|
Paolo Leoncini wrote:
>
> > Scott McMillan wrote:
> >
> > > 2) I may have found a bug. Not knowing the 3ds format at all, I
> > > cannot be sure. It involves the parsing texture scale and offset
> > > parameters starting at line 343 (of PLIB version 1.2.0). Shouldn't
> > > parse_uscale() stick the value into element 0 of the texture_scale?
<snip>
> I modified Per Liedman's 3DS loader in this way since 3DS files exported by
> 3DStudio Max (3.0) present such u-v scale swap (coming from the
> repetition/tiling param). Have you tried with any datafile?
(I forwarded this bug report message from Scott - I don't know if he's subscribed here)
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X