Discussion - proposal to extend !TEXMAP specification


RE: Discussion - proposal to extend !TEXMAP specification
#51
(2026-02-19, 16:51)Max Murtazin Wrote: In short, when you use anything non-raster as a texture, you gotta rasterize it at some step, and that step would most likely be before supplying it to the renderer, and, as such, you just won't be able to do properly scale resolution. While you *can* write a custom renderer that would rasterize the texture at "render-time", most people simply won't, as it's hard, requires custom approach (so not supported natively by stuff like OpenGL) and not best performance-wise (which is important for real-time renderers)

That's pretty much as I'd expect, though I should emphasize nothing in the proposed specification should preclude someone from writing such a renderer if they felt motivated to do so. Roland's proposed implementation may have inspired my interest in this topic, but it's not the only possible implementation, so the proposed extension to TEXMAP should be seen as enabling, but separate from, that specific implementation.

On the subject of resolution, it's my understanding that with a mip mapping approach, you start with a "master" resolution and downsample from there, so you don't lose performance or degrade the visual at lower zoom levels. Conversely, if the master resolution is set high enough—and this would be user-configurable, not set by the spec—you could certainly get acceptable render quality up to a very respectable zoom level.
Reply
RE: Discussion - proposal to extend !TEXMAP specification
#52
(2026-02-19, 18:23)Roland Melkert Wrote: True, but the main advantage (imho) is it doesn't have to be a 'normal' texture. You could eg store material parameters (per texture pixel) instead of rgb values.

For LDCad's test run I'm planning to generate just a simple rgba texture (using FBO) first though. 

Probably using a  (configurable) 10pixels/ldu resolution.

I will add that in theory a program could also scale the size of the generated textures based on how many are present in the model and the characteristics of the machine being run on (in addition to how big the geometry is in LDraw units).

Regarding using LDU as a hint for size, that does presuppose that the LDraw geometry is done at a scale that matches the projected area for the texture. There's no particular reason for this to be the case, and one texture can even be used at multiple scales. However, it should probably be recommended that the LDraw geometry in the pseudo-texture match the scale it's being projected at.
Reply
RE: Discussion - proposal to extend !TEXMAP specification
#53
This definitely looks like that using a LDraw file as a source image ia a good idea, as it solves several shortcomings of current implementations (eg. render of metallic paints).
...and a related idea: the LDraw pattern used as image does not need to be flat. Not only it can be layered, simplifying the drawing process (as already tested by Roland), but also formed! I think that we could very easily "convert" many existing 3D patterns (eg. the minifig heads) to use the new specification. Legacy renderers would still used current formed pattern as fallback, the new ones would apply the existing pattern onto the raw shape, eliminating the crumbled pattern effect and allowing for clean primitive substitution...
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)