LDraw.org Discussion Forums
TEXMAP extension thoughts and findings. - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: TEXMAP extension thoughts and findings. (/thread-13633.html)

Pages: 1 2 3 4


RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-12

(2014-08-11, 18:48)Roland Melkert Wrote:
Benjamin Moody Wrote:On the subject of the TEXMAP spec, another serious issue is the definition of gloss maps

I currently chose to ignore the gloss map option as I was unsure of it's use thinking material properties should be handled by the color number exclusively unless it act's like a mask (which I suspect it is intended to do).

GLOSSMAP is there to allow for reflective ink to render as it does on the actual part.

Take for example this Rock Raiders Torso:

973pag.jpg

The torso has a combination of elements, some of which are opaque (all the black edge lines), some of which might be semi-transparent (not a lot on this torso, I don't think), some of which has a texture that is semi-reflective (most of his vest, though the photo doesn't show this really well), and some of which have a definite solid reflection (the silver ink on the wrench and undershirt).  The GLOSSMAP would be used to indicate texels that should render with high reflectivity, so that the wrench and other aspects would "sparkle" or "shine" when changing the perspective of either the light source or the view point.  If the alpha channel (transparency channel in modern Photoshop) were viewed, it would look like a solid wrench shape, solid undershirt shape, with random speckle over the surface of the vest, for the various points that light should reflect.

As to Benjamin's issue about the RGB being reserved, I believe those should all be set to 0, so the image would appear black in background color, but appear masked (when viewed, for example as a PNG with the alpha channel in effect) to just the alpha values that dictated the gloss.  Had someone implemented them as all FF, we could have dealt with it (all white).

One bit of thinking was that one or more of those channels might later be used for a bump map definition or some other effect(s).  But we were already attempting to build an extension bridge with the GLOSSMAP definition (unproven, just theoretical), so we didn't define those for use 5 years ago, we only reserved them.  We didn't want those three "extra" channels to go to waste, and have to keep glomming on new PNGs with each new feature.

      -- joshua


RE: TEXMAP extension thoughts and findings. - Roland Melkert - 2018-01-12

(2018-01-12, 18:31)Joshua Delahunty Wrote: If I'm understanding correctly, the spec would not change from a user perspective, only the technical discussion talking about how the u-v are calculated?  The user specifies the base "center" of the wrapped texture around the cylinder, and the renderer will correct for the fact that this doesn't line up with expectations for PLANAR, or are you saying the user should specify P3 as the top middle point of the texture application?
I'm ok ether way, just wanted to bring this oddity/ambiguity to light as support for cylindrical textured parts is still very limited so changing something now won't break much.


(2018-01-12, 18:31)Joshua Delahunty Wrote: BTW, I think it's interesting the way you're using FALLBACK above.  FALLBACK was intended to allow "dual-use" decorated parts.  The existing geometric designs (we called this Design By Architecture) would go in the FALLBACK section, and the new, often-less-complicated geometry would appear in 0 !: lines.  The intent being that TEXMAP parts could be issued in the wild that would not break existing implementations (such as MLCAD).
Following the spec, your last example should work just as well with the less-work-intensive:
Makes sense, I'll have to check my implementation.

edit: seems to be ok in LDCad 1.6a


(2018-01-12, 18:31)Joshua Delahunty Wrote: I'm also a HUGE fan of the fact that you double-space between triplets.  We do this in all of our experiments, Foundry actually outputs LDR files in that format.  It makes things SO much easier to follow.  If I had my way (ha), it would be a required standard of LDRAW official files.

Edit: forgot to response to this, I can go even 'weirder' if you like Smile :
Code:
1 16   0 0  3.712    1.2374 0  1.2374   0 1 0   -1.2374 0  1.2374   ldcConRing-3-4.dat
1 16   0 0  1.237    1.2374 0  1.2374   0 1 0   -1.2374 0  1.2374   ldcConRing-1-4.dat
1 16   0 0  1.237   -1.2374 0 -1.2374   0 1 0    1.2374 0 -1.2374   ldcConRing-1-4.dat
1 16   0 0 -1.237    1.2374 0  1.2374   0 1 0   -1.2374 0  1.2374   ldcConRing-1-4.dat
1 16   0 0 -1.237   -1.2374 0 -1.2374   0 1 0    1.2374 0 -1.2374   ldcConRing-1-4.dat
1 16   0 0 -3.712   -1.2374 0 -1.2374   0 1 0    1.2374 0 -1.2374   ldcConRing-3-4.dat



RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-12

(2018-01-12, 21:39)Roland Melkert Wrote:
(2018-01-12, 18:31)Joshua Delahunty Wrote: If I'm understanding correctly, the spec would not change from a user perspective, only the technical discussion talking about how the u-v are calculated?  The user specifies the base "center" of the wrapped texture around the cylinder, and the renderer will correct for the fact that this doesn't line up with expectations for PLANAR, or are you saying the user should specify P3 as the top middle point of the texture application?
I'm ok ether way, just wanted to bring this oddity/ambiguity to light as support for cylindrical textured parts is still very limited so changing something now won't break much.

What have you set-up in LDCad at this point?  I recently reported a TEXMAP issue to Leonardo Zide about LeoCAD and as part of that conversation he reminded me that he's ready to implement CYLINDRICAL and SPHERICAL (he was one of the first to do PLANAR) as soon as I gave him info from the spec -- and he has been for years Undecided.

Believe it or not, making the relationship of P1-P2-P3 so different from that of PLANAR was purposeful.  I had to remember back 8 years as to why we tried to go that way, and as I recall it, we wanted a strong differentiation from how the points worked in a planar example (all points basically "on" the texture) to how they worked in CYLINDRICAL (two off-texture, and the third at a midpoint rather than a corner).

That said, while I objected to changes to the spec because of a large volume of work I'd done defining PLANAR TEXMAP parts between 2009 and adoption of the standard, since both Benjamin and yourself found it counter-intuitive, I'd be willing to have this change to CYLINDRICAL opened up and potentially changed.  Unfortunately, the spec specifically forbids change without ratification of the LSC, which could make it tough.

Again, how does LDCad work currently? I'll ask Leo to mirror that work, and if the only two working examples are out of spec, at least they will be consistent.
------
Side notes: 

Yes, 'a' was meant to be expressed in degrees. 

CYLINDRICAL was designed specifically because PLANAR textures would start to shear/warp at the edges if one textured the "entire" face of the mini-figure; and it was expected to help solve that particular issue.  SPHERICAL came along for completeness.  The implementation details, PLANAR, CYLINDRICAL and SPHERICAL were all based on OpenGL source examples from "the literature" (I've yet been able to go back and find them, unfortunately), and were intended to therefore be pretty straightforward.  I regret the angst SPHERICAL has caused you guys in your attempts to implement.

CYLINDRICAL as conceived was always presumed to max out at a=180, since we'd not seen a texture that wrapped an entire cylinder at the time. If I were to use CYLINDRICAL on a mini-figure double-inked head, I would use two separate textures -- I do that now with PLANAR. I suppose by extension, SPHERICAL was never meant to go over a hemisphere either.

Everything about TEXMAP was meant to make it easier for end-user participation and experimentation without having to understand 3D concepts to a super high degree (this is also why we focused on PLANAR so heavily).  If the user created a TEXMAP source rectangle that ran past the extents of the geometry, that was acceptable.  If smaller, yeah, infinite outer transparency was expected -- the idea was if the heavy lifting had been skipped at the PNG generation stage, it could be "tweaked" in the texturing stage.  

We figured that after two separate renderers had been able to implement the standard without too much headache, then it would be easy to forward to other renderers.  I didn't get a blow-by-blow from Leonardo about how hard LeoCAD was, but he made it seem really simple: I asked, he implemented. 

(2018-01-12, 18:31)Joshua Delahunty Wrote: BTW, I think it's interesting the way you're using FALLBACK above.  FALLBACK was intended to allow "dual-use" decorated parts.  The existing geometric designs (we called this Design By Architecture) would go in the FALLBACK section, and the new, often-less-complicated geometry would appear in 0 !: lines.  The intent being that TEXMAP parts could be issued in the wild that would not break existing implementations (such as MLCAD).
Following the spec, your last example should work just as well with the less-work-intensive:

Quote:
Quote:Makes sense, I'll have to check my implementation.

Again, it was meant to keep things really easy.  If a part never had DBA designs in it, it shouldn't have nor need FALLBACK or cryptic 0 !: lines

I think I saw you putting in GLOSSMAP in some examples as well; that's meant to be an optional parameter.  if it's absent, no problem, if it's present, then the PNG file should follow else it's an error.

Finally, attached is my hand-drawn diagram of what I recall (from memory and reading the spec) CYLINDRICAL to be.  Did you place P3 where it shows, or at the other end of the black line (in the colored version)?

[img]file://Users/jdelahunty/Downloads/cylindrical.jpg[/img]


RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-12

(2018-01-12, 21:39)Roland Melkert Wrote:
(2018-01-12, 18:31)Joshua Delahunty Wrote: I'm also a HUGE fan of the fact that you double-space between triplets.  We do this in all of our experiments, Foundry actually outputs LDR files in that format.  It makes things SO much easier to follow.  If I had my way (ha), it would be a required standard of LDRAW official files.

Edit: forgot to response to this, I can go even 'weirder' if you like Smile :
Code:
1 16   0 0  3.712    1.2374 0  1.2374   0 1 0   -1.2374 0  1.2374   ldcConRing-3-4.dat
1 16   0 0  1.237    1.2374 0  1.2374   0 1 0   -1.2374 0  1.2374   ldcConRing-1-4.dat
1 16   0 0  1.237   -1.2374 0 -1.2374   0 1 0    1.2374 0 -1.2374   ldcConRing-1-4.dat
1 16   0 0 -1.237    1.2374 0  1.2374   0 1 0   -1.2374 0  1.2374   ldcConRing-1-4.dat
1 16   0 0 -1.237   -1.2374 0 -1.2374   0 1 0    1.2374 0 -1.2374   ldcConRing-1-4.dat
1 16   0 0 -3.712   -1.2374 0 -1.2374   0 1 0    1.2374 0 -1.2374   ldcConRing-3-4.dat

Nothing weird to me about this.  If I could go back in time, I'd suggest to James that he use it (though I've always been more the numbers guy than another parts guy).  I think it's that important, and I've OFTEN done this with the signs on numbers, when the files all relate to one another.


RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-12

(2014-08-14, 20:42)Roland Melkert Wrote: LDView doesn't support the cylindrical projection yet, it seems to crash as a result.

BTW, I tried CYLINDRICAL in a recent build of LDView (I was hoping Travis had finally gotten to it), and while it didn't work, the part didn't crash LDView either.

FWIW.


RE: TEXMAP extension thoughts and findings. - Roland Melkert - 2018-01-13

(2018-01-12, 23:00)Joshua Delahunty Wrote: Again, how does LDCad work currently? I'll ask Leo to mirror that work, and if the only two working examples are out of spec, at least they will be consistent.
I've checked the sourcecode as it has been along time since I touched that part of the code, and it seems I'm using p3 at the same level as p1. But revisiting this now makes me want to change that (I'm about to release 1.6b anyway) to follow the spec and just invert the texcoord distance instead.

Current source of interest:
Code:
TLDCylindricalTextureInfo::TLDCylindricalTextureInfo(TGL2DTexture *tex, const TGLVector3d &p1, const TGLVector3d &p2, const TGLVector3d &p3, const double angle) :
 inherited(tex),
 topCen(p1), botCen(p2), nor(p1-p2), restDir(p3-p1),
 angle(deg2Rad(angle)), angleIs360(angle>=360.0 || angle<=-360.0) {

 nor.normalize(len);
 restDir.normalize();
};

void TLDCylindricalTextureInfo::calcUV(TGLVector3f **pnts, const int pntCnt, TGLVector2f *uv) {

 //Alles via vec3d tbv rounding errors
 TGLVector3d baseDir(false), curDir(false), pnt(false);
 double baseAngle(0.0), curAngle;

 for (int i=0; i<pntCnt; i++)
 {
   pnt.init(*pnts[i]);
   TGLVector2f &tc=uv[i];

   pnt.calcDirectionTo(botCen, nor, curDir);
   curDir.inverse(); //moet van midden naar buiten net als restDir

   curAngle=nor.calcSignedAngleBetween(curDir, i==0 ? restDir : baseDir);
   if (i==0)
   {
     baseDir=curDir;
     baseAngle=curAngle;
   }
   else
     curAngle+=baseAngle;

   tc.u=0.5+curAngle/angle;
   tc.v=distanceToPlane(pnt, nor, topCen, nor)/len; //afst tot top
 }
};

edit: A change isn't a big deal imho as officially the cyl/sph implementations in LDCad are still 'experimental'


RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-14

(2018-01-13, 18:14)Roland Melkert Wrote:
(2018-01-12, 23:00)Joshua Delahunty Wrote: Again, how does LDCad work currently? I'll ask Leo to mirror that work, and if the only two working examples are out of spec, at least they will be consistent.
I've checked the sourcecode as it has been along time since I touched that part of the code, and it seems I'm using p3 at the same level as p1. But revisiting this now makes me want to change that (I'm about to release 1.6b anyway) to follow the spec and just invert the texcoord distance instead.

Current source of interest:
Code:
TLDCylindricalTextureInfo::TLDCylindricalTextureInfo(TGL2DTexture *tex, const TGLVector3d &p1, const TGLVector3d &p2, const TGLVector3d &p3, const double angle) :
 inherited(tex),
 topCen(p1), botCen(p2), nor(p1-p2), restDir(p3-p1),
 angle(deg2Rad(angle)), angleIs360(angle>=360.0 || angle<=-360.0) {

 nor.normalize(len);
 restDir.normalize();
};

void TLDCylindricalTextureInfo::calcUV(TGLVector3f **pnts, const int pntCnt, TGLVector2f *uv) {

 //Alles via vec3d tbv rounding errors
 TGLVector3d baseDir(false), curDir(false), pnt(false);
 double baseAngle(0.0), curAngle;

 for (int i=0; i<pntCnt; i++)
 {
   pnt.init(*pnts[i]);
   TGLVector2f &tc=uv[i];

   pnt.calcDirectionTo(botCen, nor, curDir);
   curDir.inverse(); //moet van midden naar buiten net als restDir

   curAngle=nor.calcSignedAngleBetween(curDir, i==0 ? restDir : baseDir);
   if (i==0)
   {
     baseDir=curDir;
     baseAngle=curAngle;
   }
   else
     curAngle+=baseAngle;

   tc.u=0.5+curAngle/angle;
   tc.v=distanceToPlane(pnt, nor, topCen, nor)/len; //afst tot top
 }
};

edit: A change isn't a big deal imho as officially the cyl/sph implementations in LDCad are still 'experimental'

I attempted to test CYLINDRICAL with LDCad last night, and either got no image (P3 even with P1) or a scrambled one (P3 even with P2).  It was very strange.

In other news, my buddy changed Foundry last night to render textures correctly on transparent geometry, something that none of the platforms currently does right (including Foundry, as the reference platform).  LeoCAD is close, he's using a shader to get the desired effect.

(The issue is, nearly every renderer will render the texture transparently when applied to transparent geometry, when the alpha of the texture and the alpha of geometry need to combine, with opaque alpha on the texture overriding any alpha of the underlying part.  Both GL_DECAL and GL_REPLACE give the wrong results).  I presumed we'd HAVE to go to a shader solution (something I don't really mind because it was always presumed to be needed for proper GLOSSMAP support), but Foundry is apparently doing a double render manuever to get the desired results.


RE: TEXMAP extension thoughts and findings. - Roland Melkert - 2018-01-14

(2018-01-14, 0:52)Joshua Delahunty Wrote: I attempted to test CYLINDRICAL with LDCad last night, and either got no image (P3 even with P1) or a scrambled one (P3 even with P2).  It was very strange.

Seems to work fine for me (in 1.6a):
[attachment=3026]

Using
Code:
0 Cyl texmap test
0 UNOFFICIAL PART
0 BFC CERTIFY CCW

1 16 0 0 0 1 0 0 0 1 0 0 0 1 s\3626bs02.dat
1 16 0 4 0 13 0 0 0 13 0 0 0 -13 1-8cyli.dat
1 16 0 4 0 -13 0 0 0 13 0 0 0 -13 1-8cyli.dat
1 16 0 4 0 13 0 0 0 13 0 0 0 13 2-4cyli.dat
1 16 0 4 0 0 0 8 0 -6.4 0 8 0 0 t04o6250.dat
1 16 0 4 0 -8 0 0 0 -6.4 0 0 0 8 t04o6250.dat
1 16 0 17 0 0 0 -8 0 6.4 0 8 0 0 t04o6250.dat
1 16 0 17 0 8 0 0 0 6.4 0 0 0 8 t04o6250.dat
1 16 0 4 0 0 0 -8 0 -6.4 0 -8 0 0 t04o6250.dat
1 16 0 4 0 8 0 0 0 -6.4 0 0 0 -8 t04o6250.dat
1 16 0 17 0 0 0 8 0 6.4 0 -8 0 0 t04o6250.dat
1 16 0 17 0 -8 0 0 0 6.4 0 0 0 -8 t04o6250.dat


0 !TEXMAP START CYLINDRICAL 0 4 0  0 17 0   0 4 -13  90 smile.png
1 16  0 4 0  -9.1923 0 9.1923  0 13 0  -9.1923 0 -9.1923  1-4cyli.dat
0 !TEXMAP END
and
Code:
0 Cyl texmap test 2
0 UNOFFICIAL PART
0 BFC CERTIFY CCW

0 !TEXMAP START CYLINDRICAL 0 4 0  0 17 0   0 4 -13  90 smile.png
1 16  0 0 0  1 0 0  0 1 0  0 0 1 3062a.dat
0 !TEXMAP END

As you see it uses P3 at the top, I will change this for 1.6b unless anyone thinks bot planer and cylindrical should use top for uniformity ?


(2018-01-14, 0:52)Joshua Delahunty Wrote: In other news, my buddy changed Foundry last night to render textures correctly on transparent geometry, something that none of the platforms currently does right (including Foundry, as the reference platform).  LeoCAD is close, he's using a shader to get the desired effect.

(The issue is, nearly every renderer will render the texture transparently when applied to transparent geometry, when the alpha of the texture and the alpha of geometry need to combine, with opaque alpha on the texture overriding any alpha of the underlying part.  Both GL_DECAL and GL_REPLACE give the wrong results).  I presumed we'd HAVE to go to a shader solution (something I don't really mind because it was always presumed to be needed for proper GLOSSMAP support), but Foundry is apparently doing a double render manuever to get the desired results.
Transparent is very problematici ndeed (especially since LDCad 1.x uses fixed piped line), it also has to do with draw order on top of the normal trans draw order issues.

2.0 uses >= GL 3.0 so custom shaders for everything will have to revisit the problem when the time comes.


RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-14

(2018-01-14, 20:46)Roland Melkert Wrote:
(2018-01-14, 0:52)Joshua Delahunty Wrote: I attempted to test CYLINDRICAL with LDCad last night, and either got no image (P3 even with P1) or a scrambled one (P3 even with P2).  It was very strange.

Seems to work fine for me (in 1.6a):

<snip>

Do you have smile.png available for download on the web?


Roland Melkert> As you see it uses P3 at the top, I will change this for 1.6b unless anyone thinks bot planer and cylindrical should use top for uniformity ?

[I admit my point following is of a semantic nature only]

I would argue the top would be for *intuitiveness* (rather than uniformity), since the triangle formed by CYLINDRICAL is orthogonal to the triangle defined for PLANAR (and my original reasoning was, put P3 at the base so that the part designer could try to remember that the triangle for PLANAR was wider at top than at bottom, and the plane of the triangle faces the viewer, whereas the CYLINDRICAL had the wider part at the bottom, and was "viewed" edge-on (also in PLANAR P3 defines an endpoint, while in CYLINDRICAL it defines a midpoint).  I was specifically thinking that making them as different as possible in all ways was better than having things in common.

I'm not arguing it should not change (as intuitiveness is obviously subjective), I am saying that I don't personally feel that P3 at "top" is uniform with how PLANAR is defined.  I'd be happy with P3 in either location, and if more people (so far, 2 to my 1) felt it makes more sense in the top position, that's far more important than my initial intention (putting it at the bottom).

(2018-01-14, 0:52)Joshua Delahunty Wrote: In other news, my buddy changed Foundry last night to render textures correctly on transparent geometry, something that none of the platforms currently does right (including Foundry, as the reference platform).  LeoCAD is close, he's using a shader to get the desired effect.

(The issue is, nearly every renderer will render the texture transparently when applied to transparent geometry, when the alpha of the texture and the alpha of geometry need to combine, with opaque alpha on the texture overriding any alpha of the underlying part.  Both GL_DECAL and GL_REPLACE give the wrong results).  I presumed we'd HAVE to go to a shader solution (something I don't really mind because it was always presumed to be needed for proper GLOSSMAP support), but Foundry is apparently doing a double render manuever to get the desired results.
> Transparent is very problematici ndeed (especially since LDCad 1.x uses fixed piped line), it also has to do with draw order on top of the normal trans draw order issues.

That sounds like some of the issues Travis is facing with LDView.

> 2.0 uses >= GL 3.0 so custom shaders for everything will have to revisit the problem when the time comes.

I look forward to a really good textured, bump-mapped rubber eventually... ;-)

      -- joshua


RE: TEXMAP extension thoughts and findings. - Michael Horvath - 2018-01-15

Does MLCad support texmaps? I'm guessing not.