Invisible texmap pattern


Invisible texmap pattern
#1
This part
[Image: 6110077.jpg]
is now present at the Part Tracker, but the TEXMAP pattern is not visible from behind, when I use it in LDCad, on a transparent part.


Is it possible to combine a TEXMAP pattern with a BFC NOCLIP ?
If so, how should a correct file syntax look like?
Reply
RE: Invisible texmap pattern
#2
(2017-03-24, 16:25)Magnus Forsberg Wrote: This part
[Image: 6110077.jpg]
is now present at the Part Tracker, but the TEXMAP pattern is not visible from behind, when I use it in LDCad, on a transparent part.


Is it possible to combine a TEXMAP pattern with a BFC NOCLIP ?
If so, how should a correct file syntax look like?

First of all, please note that the same thing happens in LDView. In LDView, it's definitely due to a bug. (Unfortunately, it's a bug that would take a VERY long time to fix, and probably won't be fixed.) The bug in LDView is that LDView doesn't support TEXMAPs being applied to transparent surfaces, so the surface the texture is on is opaque. The reason that this relates to BFC is that in LDView, BFC is never applied to transparent surfaces. So if it weren't for this bug, the texture would be visible from the back side in LDView.

I'm not sure what happens in LDCad. It could be that LDCad applies BFC to transparent surfaces. If so, I would argue that that is a bug. It also could be that LDCad doesn't support TEXMAP on transparent surfaces. That would also be a bug.

The following might work, but isn't appropriate in an official file, since the disappearing texture is due to a renderer bug and not a part bug:

Code:
0 Dish  4 x  4 Inverted with White and Aqua Swirl Pattern
0 Name: 3960p0b.dat
0 Author: Philippe Hurbain [Philo]
0 !LDRAW_ORG Unofficial_Part
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 BFC CERTIFY CW

0 !KEYWORDS Round, Elves

1 16 0 0 0 1 0 0 0 1 0 0 0 1 s\3960s01.dat
0 !TEXMAP START PLANAR -40 0 40 40 0 40 -40 0 -40 3960p0b.png
0 !: 1 16 0 0 0 1 0 0 0 1 0 0 0 1 s\3960s03.dat
0 !: 0 BFC INVERTNEXT
0 !: 1 16 0 0 0 1 0 0 0 1 0 0 0 1 s\3960s03.dat
0 !TEXMAP FALLBACK
1 15 0 0 0 1 0 0 0 1 0 0 0 1 s\3960p2b.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 s\3960p2a.dat
0 !TEXMAP END

For reasons that I don't understand, the above doesn't work in LDView. I will be investigating that. What it's supposed to do is include a second copy of the textured geometry, and have that second copy face the opposite direction. It doesn't work, and I don't yet know why.
Reply
RE: Invisible texmap pattern
#3
(2017-03-24, 18:17)Travis Cobbs Wrote: For reasons that I don't understand, the above doesn't work in LDView. I will be investigating that. What it's supposed to do is include a second copy of the textured geometry, and have that second copy face the opposite direction. It doesn't work, and I don't yet know why.

I won't show in LDCad ether, not because the texture isn't rendered (it does show if you remove the s\3960s01.dat line, but because of the rendering order I think.

Transparent parts aren't 100% in LDCad ether indeed, I've had a discussion about this very part with Philo this week as he expeted the patterned part of the png to be non transparent even for transparent parts.

I'm going to make some tweaks for the next version but I doubt it'll be perfect as I'm currently restricted by the fixed OpenGL pipeline. The 2.0 rendering engine will use all custom shaders so things should be better once that gets going. Hopefully just in time for official parts using textures Smile

edit: confirmed, for LDCad, it is/was the rendering order I swapped something around and now Travis' version does show the texture on both sides.
Reply
RE: Invisible texmap pattern
#4
(2017-03-24, 18:17)Travis Cobbs Wrote: For reasons that I don't understand, the above doesn't work in LDView. I will be investigating that. What it's supposed to do is include a second copy of the textured geometry, and have that second copy face the opposite direction. It doesn't work, and I don't yet know why.
Well, I've discovered that textured geometry in LDView apparently isn't paying attention to BFC INVERTNEXT (at least not when it's two levels of indirection away), so that explains why the code I supplied isn't working. That's a bug I should hopefully be able to track down and fix.
Reply
RE: Invisible texmap pattern
#5
Any development in the bug hunt here?.
Is the syntax in the file correct, or do we need to change the part?
Reply
RE: Invisible texmap pattern
#6
(2017-04-17, 14:39)Magnus Forsberg Wrote: Any development in the bug hunt here?.
Is the syntax in the file correct, or do we need to change the part?

In my opinion, the part is correct.
Reply
RE: Invisible texmap pattern
#7
(2017-04-17, 19:04)Travis Cobbs Wrote:
(2017-04-17, 14:39)Magnus Forsberg Wrote: Any development in the bug hunt here?.
Is the syntax in the file correct, or do we need to change the part?

In my opinion, the part is correct.

I agree, but we might need to clarify the texmap spec on how transparent parts should be rendered.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)
Forum Jump:


Users browsing this thread: 1 Guest(s)