Discussion - proposal to extend !TEXMAP specification

[Travis Cobbs]

Using a PNG this way would not give the same results, as you'd be locked into the resolution of that PNG file before you even start the program. Projected LDraw geometry would be rasterized at the other end of the pipeline, taking into account the current view/zoom level, plus maybe user settings, etc. More scalable without increasing file size.

Maybe Roland will be rendering on the fly based on things like that, but if this goes through, I expect LDView to render the texture at file load time. Also, I don't think that rendering to texture each frame based on projected size would be performant, although I could be wrong about that.

Would authors use it? I sure would. Being able to author a flat pattern and have it projected with all the crispness of LDraw geometry onto a cylindrical or spherical part, without messing up the smoothness of that curvature—or onto something much more complex, like a Muppet head or a sheep or something? I currently consider that beyond my skill level, but the projection method seems accessible to me. My feeling is that it will encourage other, less experienced part authors to try their hand at pattern authoring.

As mentioned above, I really don't think that it's going to be equivalent to the original geometry, because I don't think it's going to be rendered to a texture each frame. It will allow for flat LDraw geometry to be projected onto arbitrary surfaces, but that will happen as a texture.

But besides what authors want, keep in mind that it benefits the reviewing and spec side of things, too. We've kind of set the standard (and rightly so, I think) that PNG textures aren't ideal for most patterns, but we also don't hold parts solely for being texmapped (and also rightly so, I think). This creates an extra workload down the line, as authors feel the need to re-takeup a texmapped part to vectorize the pattern. Being able to have patterns done the "right" way the first time, and more easily and with better results that the current method, has got to be worthwhile.

It could be me, but I think that you are overly optimistic about what this is going to look like at runtime. To me, it's just going to be a texture in a different format, but it seems like you think it is going to magically produce full vector-quality output at runtime. Maybe I'm missing something, and maybe Roland plans to implement it the way that you are expecting, but if so, I totally misunderstood the whole thread. Roland, are you expecting the flat LDraw geometry to get projected onto the target geometry, or are you planning to render to texture and then project that? And if the latter, are you rendering to texture at load time or at draw time?

It does also have the potential to greatly simplify the library; if the concept proves successful, it could obviate the need for the entire category of patterned parts. All you need would be a collection of pattern files, and the base parts to project them onto.

And, don't forget the possible benefits to non-patterned parts as well. If projected LDraw code can solve some of the more irksome rendering anomalies we currently have, it's certainly worth implementing.

The same could be done with the existing PNG textures. Remember, the suggested change is to allow LDraw files to be used in place of PNG files. Everything else stays the same.