Discussion - proposal to extend !TEXMAP specification

[N. W. Perry]

Been thinking about implementing a proof of concept in a special build of LDCad.

Needed:
- Projection (probably best to let the spec define a static one like Ortho looking at the z direction)

I'm a little ignorant on this side of things. What projection info is needed that's different for LDraw code than the three methods we have now for PNG?

Certainly ortho would be commonly used; for authoring patterns on complex shapes, you'd most often be working from orthogonal photos. (Technically a perspective method should be used, but the effect is so minimal at ldu scale…)

At one time I was thinking that you could project onto a primitive surface by using its filename as an input parameter. But I'm not sure that makes sense technically (all the prims eventually boil down to planar, cylindrical or spherical anyway).

- Texture resolution (pixels per LDU=> probably best as an internal setting or render quality depended).

Should be determined by current screen resolution/viewbox, although this could be governed by render quality user settings in the tool.

- Lighting settings (probably best to use none)

Can't think of a use for this during the mapping phase (as opposed to final render)?

- Texture background color (probably best to always use 'transparent')

Probably either transparent or main color. Presumably you would not be projecting a background, only the pattern itself. Though setting a background color could have uses for non-pattern projected code.

So imho the whole thing could work using a meta like:

Code:

0 !TEXMAP (START | NEXT) <method> <parameters> <pngfile|ldrawFile> [GLOSSMAP pngfile]

Which would let renderer decide the size of the texture based on the source's min/max x/y coordinates.

or something more flexible:

Code:

0 !TEXMAP (START | NEXT) <method> <parameters> <pngfile|ldrawFile> [GLOSSMAP pngfile] [SURFACE W H ofsX ofsY]

Where the ldraw source x/y coordinates will be added to ofsX,ofsY within a base surface of WxH (ldu). This could be applied to png's too but using pixels instead of ldu.

How is the size determined currently for png? Is there a need to add the scalability option? (I might call it "SIZE" rather than "SURFACE", as to me that suggests material/finish settings rather than dimensions.)