LDraw.org Discussion Forums

Full Version: Texmap render issues on PT
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Glitches in both the image preview and the 3D render of https://www.ldraw.org/cgi-bin/ptdetail.c...092p01.dat


The preview shows thick yellowish lines around the edges of the texture images, and also has some odd vertical lines visible in the pits:
[attachment=5322]

The 3D render is missing some textures entirely, and has distorted many of the others:
[attachment=5323]

The above seems fairly consistent - I've forced a reload of the page, and tried in both Firefox and Edge, and I get the same results.
Thanks for submitting a fairly complicated file to test textures on.

For debugging purposes I will have to reduce the file as much as possible in order to home in on the issues. You say the file loads correctly in LDCad. Can you please share a screenshot from that, since I cannot use LDCad on the device I'm using for debugging?

Debugging stuff like this typically takes some days, so please have patience.
(2020-06-02, 15:54)Alex Taylor Wrote: [ -> ]Glitches in both the image preview and the 3D render of https://www.ldraw.org/cgi-bin/ptdetail.c...092p01.dat


The preview shows thick yellowish lines around the edges of the texture images, and also has some odd vertical lines visible in the pits:

The preview uses LDView, and doing some digging, I see that there is a bug in LDView's snapshot functionality when textures with partial transparency are used in conjunction with the "Transparent Background" option of the snapshot saving. There also appears to be a problem with textures interfering with conditional edge lines, as well as probably another problem with textures placed over studs causing issues. I will try to track down the problems and fix them, then update the build used by the part tracker, but it could take some time.
Here's some LDCad exports:
[attachment=5328]
[attachment=5329]
[attachment=5327]
(2020-06-02, 17:52)Orion Pobursky Wrote: [ -> ]Here's some LDCad exports:
Thanks Orion.
(2020-06-02, 17:41)Travis Cobbs Wrote: [ -> ]The preview uses LDView, and doing some digging, I see that there is a bug in LDView's snapshot functionality when textures with partial transparency are used in conjunction with the "Transparent Background" option of the snapshot saving. There also appears to be a problem with textures interfering with conditional edge lines, as well as probably another problem with textures placed over studs causing issues. I will try to track down the problems and fix them, then update the build used by the part tracker, but it could take some time.

Yes, if you're referring to the three bugreports raised yesterday, that was me :-)
I have not solved the rendering issue yet, but I have a comment regarding the sizing of textures. The size of a texture will be set to a power of two (128, 256, 512, etc.) and resized each time the texture is rendered. Will it not be an advantage to restrict textures to these sizes in the parts tracker and avoid all of the client-side resizing in various programs?


As an example, each time I render this part that is having texture rendering issues, 16 resizing operations have to be performed.
(2020-06-06, 16:47)Lasse Deleuran Wrote: [ -> ]I have not solved the rendering issue yet, but I have a comment regarding the sizing of textures. The size of a texture will be set to a power of two (128, 256, 512, etc.) and resized each time the texture is rendered. Will it not be an advantage to restrict textures to these sizes in the parts tracker and avoid all of the client-side resizing in various programs?


As an example, each time I render this part that is having texture rendering issues, 16 resizing operations have to be performed.

I'd have thought the textures would be resized on loading rather than rendering.
(2020-06-06, 17:31)Alex Taylor Wrote: [ -> ]I'd have thought the textures would be resized on loading rather than rendering.
Yes, of course each time they are loaded. Otherwise the frame rate might suffer quite a bit Big Grin
(2020-06-06, 18:36)Lasse Deleuran Wrote: [ -> ]Yes, of course each time they are loaded. Otherwise the frame rate might suffer quite a bit Big Grin
Indeed :-)

So this is really a one-off hit we're talking about here, and IMO it's not appropriate to impose a technical limitation of the rendering technology onto parts authors.

The textures for this particular part are (mostly) at 320dpi.  I normally work at 640dpi or integer multiples/fractions thereof as it maps very neatly into LDUs.  Obviously the final choice of dpi is a tradeoff between the size of the image and the level of detail it needs - this one's 320 because it's not a particularly detailed set of images - but I think forcing authors to work in powers of two will lead to compromises.  For example, the top image here covers a width of 29 studs and thus is 2900 pixels wide.  The nearest powers of two being 2048 and 4096 mean that either it scales down a bit and (possibly) loses detail, or else it scales up massively for no good reason.

The other issue I see with such a restriction is that it would force the majority of texture images into having non-square pixels (or large areas of blank space, or both).
Pages: 1 2