Mantis - Croquet
Viewing Issue Advanced Details
2529 Jasmine major always 01-17-06 22:35 07-15-06 06:07
greg rivera  
0002529: ASE SubMaterials (facegroups) drawn with wrong textures
(works on pre-Jasmine release, broken with current Jasmine)
When an ASE model is imported with multiple SubMaterials, the wrong SubMaterial texture is used to draw the polygons.
Specifically, when the model has multiple (3 or more) "facegroups", the facegroups appear to use the wrong texture index.

-- Problem appeared after the "TVertexBuffer" etc. was added to Jasmine. It works properly with prior (no "TVertexBuffer") version.

-- Models with only two SubMaterials appear to be ok. But once 3+ SubMaterials are used (3 or more facegroups), the texture assignment goes weird.
Pre-jasmine, the facegroups sequence and texture sequence were matched, one uses one, facegroup 2 used texture 2, etc. Now, its all jumbled.
(Detail: yeah, its actually facegroup index 0,2,4 using texture index 0,1,2, since facegroups use two slots, so I'm referring to the sequence #, not the physical index #)

Some examples of errors (from a 20Meg database)
<<facegroup> uses <<facegroup's texture>>, and visually ok or wrong?
Obj 8:
0 uses 0, ok
1 uses 2, wrong
2 uses 2, ok
3 uses 0, wrong

Obj 37:
0 uses 1, wrong
1 uses 0, wrong
2 texture defined, but not used, ok

Obj 7:
0 uses 0, ok
1 uses 1, ok (all single or double textures seem to be fine, its the third
or more that messes things up)

Obj 8:
0 uses 0, ok
1 uses 2, wrong
2 uses 2, ok
3 uses 0, wrong

-- When comparing the vertices used by FaceGroups vs TVertexBuffer, they aren't in matching order (does this matter?). This seems strange, since the code that fills the FaceGroups appears to fill the TVertexBuffer at the same time ...
Noticed in this test sample:
I noticed three face groups, first group starting w/ vertex 1854+, second at
4+, third with 2066+
But the TVertexBuffer has the three groups in a different order, first 4+,
then 1854+, then 2066+ [^] (91,864 bytes) 01-24-06 17:56

01-18-06 16:56   
Greg, could you please make available a model that exhibits this broken behavior, as well as a screenshot of how it is supposed to look?

greg rivera   
01-24-06 18:12   
(sry for delay, thought feedback to originator was automatic ...)
This is a simpler version (original model is 1+meg even after compression)
There are two L-shaped rows, front row is separate objects, back is single object.
Both rows: series of differently colored blocks, each with one (different) texture on its front (1-5).
Front row: each block is separate object, with two submaterials: one is color, other is specific texture.
Back row: single object, with 10 submaterials -- the five colors, and the five textures. Except for being closer together (hints at 'same object'), should look the same as front row.

Pre-jasmine looks just as built in 3DStudio.

The bad photo (post jasmine) has no color on the blocks, and the texture is drawn on its side face (instead of front). And second row is missing the '5'.

The photo bmps are from dropping it into an old croquet, vs a more recent croquet.
(side note: when dropping it into scene, transform is weird ... hard to walk around it ...)
Thanks for looking into this.
07-14-06 04:54   
Reminder sent to: schwa

Has there been any progress on this issue? (Mantis: 02529 regarding texture getting confused.) It's biting me on the butt right now and I don't want to have to redo effort if I don't have to.
07-14-06 05:06   
Sorry, this hasn't been on my priority list. Is this bug just in Jasmine, or in Hedgehog too? I don't know of anyone else working in Jasmine today; are you?
07-14-06 05:31   
It appears to be in hedgehog as well...or a bug just like it. I haven't had time to check against the sample files yet. But the external symptoms appear identical.

07-14-06 05:38   
I'm reposting this as a Hedgehog bug.
07-14-06 07:13   
Thanks. Did you check against the example files?...nevermind...I just did and it's definitely broken in hedgehog.

07-15-06 06:07   
Materials will be redone relatively soon (in Hedgehog), which might end up fixing the problem, so I won't be addressing this problem directly. If it is on your critical path and you end up fixing it, please let us know.

(sorry about the lack of attention to this bug... it's been a busy 6 months :-)