Texmap render issues on PT

[Alex Taylor]

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 3D render is missing some textures entirely, and has distorted many of the others:
   

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.

[Lasse Deleuran]

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.

[Travis Cobbs]

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.

[Orion Pobursky]

Here's some LDCad exports:
   
   
   

[Lasse Deleuran]

Here's some LDCad exports:

Thanks Orion.

[Alex Taylor]

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 :-)

[Lasse Deleuran]

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.

[Alex Taylor]

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.

[Lasse Deleuran]

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

[Alex Taylor]

Yes, of course each time they are loaded. Otherwise the frame rate might suffer quite a bit

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).

[Lasse Deleuran]

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).

I am not aware of texture loaders that do not use powers of two. The way I see it, you are compromising your work by not scaling.

If you perform the scaling, then you, the author, decides if you want to scale up or down and you, the author, decides the type of scaling to use (nearest neighbour, bilinear interpolation, etc. Or you can let it be up to the texture loaders to decide it all while the end users wait.

I am fine with letting it be up to authors to decide if they want to control the size and type of scaling for texture, but I think they should be aware of the disadvantages.

[Travis Cobbs]

Yes, of course each time they are loaded. Otherwise the frame rate might suffer quite a bit

When the TEXMAP spec was created, a conscious decision was made to favor ease of authorship over ease of rendering. It is expected that anyone with the knowledge to write a renderer also has the knowledge to scale the textures as-needed for their renderer to work. This is also why the TEXMAP spec specifies projected textures instead of UV-mapped textures.

[Lasse Deleuran]

The errors in the 3D render have been fixed in the main library - the changes just have to be pushed to the LDraw pages.

I found one error and one misinterpretation. The error caused texmaps to not work on sub-models, which is why the floor was blank. This was easily fixed.

The misinterpretation is what caused the textures on the sides of the pools to be stretched. The issue is due to the undefined behaviour of "negative distances" in the specification. See this cutout as an example:
The blue triangle represents the texmap projection coordinates:

0 !TEXMAP START PLANAR 0 -20 -160  0 -20 -80  0 0 -160 6092p01pit2side1.png

The green triangle and the lines show where the projection intersects a section of the part.
As you can see, the upper point lies outside of the projected area. The UV value for this point will thus match that of the point below it.

By changing the code from:

[color=#24292e][size=small][font=-apple-system, system-ui,][color=#24292e][size=x-small][font=SFMono-Regular, Consolas,]    [color=#d73a49]let toPlane = (n, D) => Math.abs(n.x*p.x + n.y*p.y + n.z*p.z + D);[/color]

to:

[/font][/size][/color][color=#24292e][size=x-small][font=SFMono-Regular, Consolas,]    [color=#d73a49]let toPlane = (n, D) => n.x*p.x + n.y*p.y + n.z*p.z + D;[/color]

the texture is placed as intended.[/font][/size][/color][/font][/size][/color]



[color=#24292e][size=small][font=-apple-system, system-ui,]PS. In the console you can also see how the three.js texture loader is scaling down the texture and does so rather crudely.[/font][/size][/color]

[Orion Pobursky]

I just pulled the latest code but it looks like you've changed something since the code is now broken. I'll have to figure out what changed and fix it later.

[Lasse Deleuran]

I just pulled the latest code but it looks like you've changed something since the code is now broken. I'll have to figure out what changed and fix it later.

When was the last time you pulled the code? Recently there has been a change to LDROptions, so that "new LDR.Options" is no longer used.

[Orion Pobursky]

When was the last time you pulled the code? Recently there has been a change to LDROptions, so that "new LDR.Options" is no longer used.

I got that far. Now I'm getting a "normalLines.applyMatrix4 is not a function" error in LDRLoader.js.

[Orion Pobursky]

I got that far. Now I'm getting a "normalLines.applyMatrix4 is not a function" error in LDRLoader.js.

Nevermind. I fixed it. Pointed to the wrong three.js

[Lasse Deleuran]

Nevermind. I fixed it. Pointed to the wrong three.js

You seem to have fixed it all now. It does look a bit funky when loading the textures, but that is to be expected.

Your screenshots were also a great help when debugging.