Guys i want to make a very simple custom part. its a rectangle with a png snapped on front with transparent background. its possible to make this? (EASY WAY)
something like this. its to add into a model in a building instruction. that will be overlapped to a model
![[Image: O45tmnb.png]](https://i.imgur.com/O45tmnb.png)
(2018-11-06, 11:59)tatubias Wrote: [ -> ]Guys i want to make a very simple custom part. its a rectangle with a png snapped on front with transparent background. its possible to make this? (EASY WAY)
something like this. its to add into a model in a building instruction. that will be overlapped to a model
Probably the simplest is to use Roland's sticker generator
http://www.melkert.net/test/stickerGen.html
its possible to make the square 100% transparent (invisible) i want only the sticker visible.
I have tested several colors transparents but i still see the rectangle that helds the sticker
(2018-11-06, 15:27)tatubias Wrote: [ -> ]its possible to make the square 100% transparent (invisible) i want only the sticker visible.
I have tested several colors transparents but i still see the rectangle that helds the sticker
Two solutions (if I understand correctly your configuration, a sticker placed on a rectangular part)
The simple one is to make background of sticker to be color 16 (main color) and use it in the same color as the rectangular part.
The other one is to use special color 0x7000000 which is "invisible".
(2018-11-06, 16:17)Philippe Hurbain Wrote: [ -> ] (2018-11-06, 15:27)tatubias Wrote: [ -> ]its possible to make the square 100% transparent (invisible) i want only the sticker visible.
I have tested several colors transparents but i still see the rectangle that helds the sticker
Two solutions (if I understand correctly your configuration, a sticker placed on a rectangular part)
The simple one is to make background of sticker to be color 16 (main color) and use it in the same color as the rectangular part.
The other one is to use special color 0x7000000 which is "invisible".
what i want to make is: use the transparent background of the png so its not showed. i only want to show the ticker image only
Let me explain better with images.
1 i made a png image with transparent background, and save it as png with transparent background.
![[Image: RKFTxI7.png]](https://i.imgur.com/RKFTxI7.png)
then when i added as a TEXMAP with your app i can change the background color but i cant make it disappear.
![[Image: 5CuKet5.png]](https://i.imgur.com/5CuKet5.png)
if i use the 0x7000000 invisible color it makes transparent all the sticket and not the background.
Code:
0 My textured sticker
0 UNOFFICIAL PART
0 BFC CERTIFY CCW
1 16 0 -0.1 0 50 0 0 0 0.1 0 0 0 50 box5-12.dat
0 !TEXMAP START PLANAR -50 -0.1 50 50 -0.1 50 -50 -0.1 -50 android.png
0 !: 4 1 -50 -0.1 50 -50 -0.1 -50 50 -0.1 -50 50 -0.1 50
0 !TEXMAP FALLBACK
4 16 -50 -0.1 50 -50 -0.1 -50 50 -0.1 -50 50 -0.1 50
0 !TEXMAP END
this is how it looks when i inser it into other model
![[Image: lXxbsI1.png]](https://i.imgur.com/lXxbsI1.png)
You might try commenting out the box5-12.dat line of your sticker part. (Add "0 ", without the quotes, to the beginning of the line.) Also, change the color of the textured quad to be invisible:
Code:
0 !: 4 0x7000000 -50 -0.1 50 -50 -0.1 -50 50 -0.1 -50 50 -0.1 50
In LDView, this does what you want:
![[Image: ZNywY2l.png]](https://i.imgur.com/ZNywY2l.png)
Not sure about LDCad, though. I think the LDraw texturing spec makes it ambiguous about what the correct behavior is for the above. If LDCad has the texture's opacity match the underlying geometry, it won't show anything. If LDCad makes the texture itself fully opaque, it should match LDView.
There is another solution, but it's much more elaborate, and won't necessarily work. You can actually specify the bricks behind the texture inside the textured region, instead of the single quad that is there now. This also requires calculating the correct scaled texture coordinates, which the existing sticker doesn't have. Also, the bricks will be textured on both sides, so if the backs of the bricks show, it won't really work. Finally, anywhere that there aren't any bricks, the texture will be missing. But, assuming you're trying to get the texture to show on the side of a vehicle, it would work, as long as you can't see the backs of the bricks.
(2018-11-06, 18:59)Travis Cobbs Wrote: [ -> ]You might try commenting out the box5-12.dat line of your sticker part. (Add "0 ", without the quotes, to the beginning of the line.) Also, change the color of the textured quad to be invisible:
Code:
0 !: 4 0x7000000 -50 -0.1 50 -50 -0.1 -50 50 -0.1 -50 50 -0.1 50
In LDView, this does what you want:
Not sure about LDCad, though. I think the LDraw texturing spec makes it ambiguous about what the correct behavior is for the above. If LDCad has the texture's opacity match the underlying geometry, it won't show anything. If LDCad makes the texture itself fully opaque, it should match LDView.
There is another solution, but it's much more elaborate, and won't necessarily work. You can actually specify the bricks behind the texture inside the textured region, instead of the single quad that is there now. This also requires calculating the correct scaled texture coordinates, which the existing sticker doesn't have. Also, the bricks will be textured on both sides, so if the backs of the bricks show, it won't really work. Finally, anywhere that there aren't any bricks, the texture will be missing. But, assuming you're trying to get the texture to show on the side of a vehicle, it would work, as long as you can't see the backs of the bricks.
Thank you very much it did work as expected.
[img]blob:https://imgur.com/b19c8659-24c3-4219-947c-d26ba5480d79[/img]
![[Image: yQdj2wb.png]](https://i.imgur.com/yQdj2wb.png)
i did test your option before but only on ldcad. looks like the rendering is different than in ldview. ;
n ldview work ok and in ldcad the object its invisible.
(2018-11-06, 18:59)Travis Cobbs Wrote: [ -> ]Not sure about LDCad, though. I think the LDraw texturing spec makes it ambiguous about what the correct behavior is for the above. If LDCad has the texture's opacity match the underlying geometry, it won't show anything. If LDCad makes the texture itself fully opaque, it should match LDView.
The texture will become part of the underlying geometry, so it will indeed become invisible as a whole.
The ambiguity on this in the spec has come up before, but in practice I don't think you always want one or the other behavior. So we might need to make it an option somehow?
I'm not sure how to get the desired effect as wanted here using the fixed pipeline though, but I would certainly address it in the 2.0 engine.
(2018-11-06, 20:54)Roland Melkert Wrote: [ -> ] (2018-11-06, 18:59)Travis Cobbs Wrote: [ -> ]Not sure about LDCad, though. I think the LDraw texturing spec makes it ambiguous about what the correct behavior is for the above. If LDCad has the texture's opacity match the underlying geometry, it won't show anything. If LDCad makes the texture itself fully opaque, it should match LDView.
The texture will become part of the underlying geometry, so it will indeed become invisible as a whole.
The ambiguity on this in the spec has come up before, but in practice I don't think you always want one or the other behavior. So we might need to make it an option somehow?
I'm not sure how to get the desired effect as wanted here using the fixed pipeline though, but I would certainly address it in the 2.0 engine.
I agree that being able to set the transparency of the texture independently of the transparency of the underlying geometry would be useful. LDView uses two passes to draw textures (which sometimes leads to texture static). The first pass draws the textured geometry in whatever color it might be, and the second draws just the texture. The texture pass uses the opacity from the alpha channel of the PNG file, but doesn't pay attention to the underlying geometry's transparency.
This is obviously not ideal, but even before LDView worked with textures on transparent geometry, that was the only way I could figure out to support both lit and unlit textures.
(2018-11-07, 5:06)Travis Cobbs Wrote: [ -> ]I agree that being able to set the transparency of the texture independently of the transparency of the underlying geometry would be useful.
Actually, as I think about this more, I don't think it would be a good idea to make the texture's transparency an option. I think it would be better if the spec said that all textures should be applied fully opaque, and only allow partial transparency via the alpha channel in the texture. So if you have a sticker that is partially transparent, then the transparent pixels in the texture should be partially transparent.
Of course, you already said that LDCad would have trouble having the texture be opaque when the underlying geometry is transparent, so I'm not sure that clarifying the spec in this way is really fair to you.
(2018-11-08, 5:38)Travis Cobbs Wrote: [ -> ] (2018-11-07, 5:06)Travis Cobbs Wrote: [ -> ]I agree that being able to set the transparency of the texture independently of the transparency of the underlying geometry would be useful.
Actually, as I think about this more, I don't think it would be a good idea to make the texture's transparency an option. I think it would be better if the spec said that all textures should be applied fully opaque, and only allow partial transparency via the alpha channel in the texture. So if you have a sticker that is partially transparent, then the transparent pixels in the texture should be partially transparent.
Of course, you already said that LDCad would have trouble having the texture be opaque when the underlying geometry is transparent, so I'm not sure that clarifying the spec in this way is really fair to you.
I was wondering about real life situations where the sticker should be transparent (like its handled in LDCad now), and couldn't think of any to be honest.
Using alpha<1.0 to make distinctions would be easy in shaders, but not in the fixed pipeline so it has to wait on 2.0
(2018-11-09, 19:44)Roland Melkert Wrote: [ -> ] (2018-11-08, 5:38)Travis Cobbs Wrote: [ -> ]Actually, as I think about this more, I don't think it would be a good idea to make the texture's transparency an option. I think it would be better if the spec said that all textures should be applied fully opaque, and only allow partial transparency via the alpha channel in the texture. So if you have a sticker that is partially transparent, then the transparent pixels in the texture should be partially transparent.
Of course, you already said that LDCad would have trouble having the texture be opaque when the underlying geometry is transparent, so I'm not sure that clarifying the spec in this way is really fair to you.
I was wondering about real life situations where the sticker should be transparent (like its handled in LDCad now), and couldn't think of any to be honest.
Using alpha<1.0 to make distinctions would be easy in shaders, but not in the fixed pipeline so it has to wait on 2.0
Im thinking in 2 options.
1 let ldcad automatically render alpha channel of the png files. and let those parts transparent.
2 they can modify the 0 !TEXMAP START PLANAR and add an extra parameter that gives you the alpha channel level from 0 opaque to 100 transpatrent.
Hello
i reopen the thread because i'm trying to recreate the 1x6 brick 3067pb02
![[Image: 250x250p.jpg?1561405074.4147894]](https://cdn.rebrickable.com/media/thumbs/parts/photos/36/3067pb02-36-187bbb60-e45b-4c7e-b29b-99a0ad2ca32b.jpg/250x250p.jpg?1561405074.4147894)
It does not exist on Stud.io or ldraw library so i tried to use a simple 3067 trans-red with the fork and cup sticker.
I create the transparent sticker with white fork and cup.
then i created a dat file into "..\ldraw\Unofficial\customparts\parts"
called 3067_fork.dat
The code inside is this:
Code:
0 ~Moved to 3067a
0 Name: 3067.dat
0 Author: [PTadmin]
0 !LDRAW_ORG Part UPDATE 2017-01
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 BFC CERTIFY CCW
0 !HISTORY 2017-12-30 [PTadmin] Official Update 2017-01
0 // Brick 1 x 6 without Centre Studs
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3067a.dat
0 !TEXMAP START PLANAR -60 0 -10 60 24 -10 -60 24 -10 3067pb02.png
4 16 -60 24 -10 60 24 -10 60 0 -10 -60 0 -10
0 !TEXMAP FALLBACK
4 16 -60 24 -10 60 24 -10 60 0 -10 -60 0 -10
0 !TEXMAP END
Tried and retried but the result is always the same. I can see right into LDCad but into Lpub3D i see this result:
![[Image: 3067-error.png]](https://i.ibb.co/KWJtRKj/3067-error.png)
Here you are the PNG i used:
![[Image: 3067pb02.png]](https://i.ibb.co/0JTk1Rm/3067pb02.png)
Where is my mistake?
Thanks for help
PS: if i change color of part to (example) red, it works prefectly.
TEXMAP parts rendering on transparent part is not an easy task. What renderer do you use in LPub3D? (configuration ->preferences -> rendering tab)
(2019-10-24, 13:24)Philippe Hurbain Wrote: [ -> ]TEXMAP parts rendering on transparent part is not an easy task. What renderer do you use in LPub3D? (configuration ->preferences -> rendering tab)
Sorry i forgot that. LDview
(2019-10-24, 13:40)Simone Wrote: [ -> ]Sorry i forgot that. LDview
Your LDraw code is a bit wrong, since it uses a part with front face and overlaps a front face with texmapped pattern. Attached a more correct version.
...but I doubt this is the source of your problem.
LDview renders front face as opaque:
[
attachment=4117]
and LDCad renders the pattern as transparent:
[
attachment=4116]
(2019-10-24, 14:45)Philippe Hurbain Wrote: [ -> ]Your LDraw code is a bit wrong, since it uses a part with front face and overlaps a front face with texmapped pattern. Attached a more correct version.
...but I doubt this is the source of your problem.
LDview renders front face as opaque:
and LDCad renders the pattern as transparent:
Also with your code i'm still getting the same behavior.
I thought I got the same result that you got with ldview. Where could I have gone wrong? Do I need to enable a particular setting on the LDview render engine?
(2019-10-24, 15:02)Simone Wrote: [ -> ]Also with your code i'm still getting the same behavior.
I thought I got the same result that you got with ldview. Where could I have gone wrong? Do I need to enable a particular setting on the LDview render engine?
OK, I finally fired LPub3D, and see the same problem as you do, on this part or other texmapped ones (transparent). I guess you'll have to file in a bug report...
https://github.com/trevorsandy/lpub3d/issues
(2019-10-24, 16:11)Philippe Hurbain Wrote: [ -> ]OK, I finally fired LPub3D, and see the same problem as you do, on this part or other texmapped ones (transparent). I guess you'll have to file in a bug report... https://github.com/trevorsandy/lpub3d/issues
Ok. Thanks for suggestion. Doing it now.
(2019-10-24, 16:22)Simone Wrote: [ -> ]Ok. Thanks for suggestion. Doing it now.
I am able to produce this behaviour with my installed instance of LDView, it is not a result of my modifications to the LPub3D instance of LDView.
The source seems to be in the LDView Snapshot module. You can validate this on your system by simply exporting a snapshot from the user interface or the command line:
Code:
"C:\Program Files\LDView\LDView64.exe" -ca0.01 -cg23,-45,3993775 -SaveWidth=1240 -SaveHeight=1753 -SaveSnapShot=C:\Users\Trevor\Desktop\LPub\Simone\customPart\3067_custom\LPub3D\3067_fork_36_1240_150_DPI_1_0.01_23_-45.png -LDrawDir=C:\Users\Trevor\LDraw -HaveStdOut=1 -vv C:\Users\Trevor\Desktop\LPub\Simone\customPart\3067_custom\test_3067pb02.ldr
[
attachment=4118]
Cheers,
Quote:The source seems to be in the LDView Snapshot module. You can validate this on your system by simply exporting a snapshot from the user interface
The snapshot above was created with snapshot export from user interface. Not perfect (no transparency) but different from yours. (Ldview 4.3 (x64) (2 Jan, 2017) )
Any plans to support texmap with native renderer?
(2019-10-25, 7:03)Philippe Hurbain Wrote: [ -> ]The snapshot above was created with snapshot export from user interface. Not perfect (no transparency) but different from yours. (Ldview 4.3 (x64) (2 Jan, 2017) )
Any plans to support texmap with native renderer?
LDView has the following option in its Primitives preferences:
- Draw transparent textures last
I discovered after the fact that you must check this option if you want things to work right. It will be removed in a future version of LDView. To set this on the command line, use -TexturesAfterTransparent=1.
(2019-10-25, 18:17)Travis Cobbs Wrote: [ -> ]LDView has the following option in its Primitives preferences:
- Draw transparent textures last
I discovered after the fact that you must check this option if you want things to work right. It will be removed in a future version of LDView. To set this on the command line, use -TexturesAfterTransparent=1.
One more thing. I think it was mentioned elsewhere in this thread, but in order for this to work right, you have to draw 3067a without the front face, and then add the textured quad with color 16. Alternatively, LDView will allow you to draw the textured quad with color 0x7000000 (invisible). If you do that, everything should look right in LDView, but it might not look right in LDCad.
Also, since you don't use 0 !: for the textured geometry, it will always be drawn. If textures are unsupported (or disabled in LDView), that will be drawn in addition to the fallback geometry. The reality is that you wouldn't want to do that. Instead, you should just get rid of the FALLBACK section.
If you update to use a subpart with everything except the front face, and then use the textured front face, you would continue use color 16 for that front face as you have it now, and wouldn't need any fallback. If you decide to use color 0x7000000 for the textured quad, it will just be invisible when texture mapping is disabled, but you definitely don't want the fallback geometry in that case either.
(2019-10-25, 18:17)Travis Cobbs Wrote: [ -> ]LDView has the following option in its Primitives preferences:
- Draw transparent textures last
I discovered after the fact that you must check this option if you want things to work right. It will be removed in a future version of LDView. To set this on the command line, use -TexturesAfterTransparent=1.
Ah - I remembered something like that, but couldn't find again that option.... I thought I had more or less the llast version ?
(2019-10-25, 18:59)Philippe Hurbain Wrote: [ -> ]Ah - I remembered something like that, but couldn't find again that option.... I thought I had more or less the llast version ?
[color=unset]I am not sure if this helps, because I do not understand anything written here.[/color]
[color=unset][
attachment=4124][/color]
[color=unset][
attachment=4125][/color]
(2019-10-25, 18:17)Travis Cobbs Wrote: [ -> ]LDView has the following option in its Primitives preferences:
- Draw transparent textures last
I discovered after the fact that you must check this option if you want things to work right. It will be removed in a future version of LDView. To set this on the command line, use -TexturesAfterTransparent=1.
Thank you Travis.
This flag is not automatically set in LPub3D. To do so you have 2 options.
1. Using LDView Preferences:
[
attachment=4122]
2. Or local/global meta command set in the model file using the new "Add Renderer Arguments" dialogue:
[
attachment=4123]
[
attachment=4126]
Don't forget to reset the appropriate cache(s) and click the editor's update button:
[
attachment=4127]
[
attachment=4128]
Cheers,
(2019-10-25, 7:03)Philippe Hurbain Wrote: [ -> ]Any plans to support texmap with native renderer?
Actually I thought this was implemented but taking a look in the code I can see that I only address half of the texmap import routines. I'll add the remaining routines shortly but I'm not sure LeoCAD will correctly apply the texmap.
Cheers,
(2019-10-25, 18:59)Philippe Hurbain Wrote: [ -> ]Ah - I remembered something like that, but couldn't find again that option.... I thought I had more or less the llast version ?
Philo, I'm not sure what is up with your version. 4.3 was released at the end of January 2018, not the beginning of January 2017. I think you have a development version that I incorrectly labeled as 4.3. The official 4.3 version should have the "Draw transparent textures last" option in its Primitives preferences (as seen in Trevor's and Johann's screenshots).
(2019-10-25, 19:09)Trevor Sandy Wrote: [ -> ]Thank you Travis.
This flag is not automatically set in LPub3D. To do so you have 2 options.
You're welcome.
Note also that if you get a result like shown in Trevor's screenshot (where the texture is only partially visible), you may be able to improve things by increasing the "Offset" setting right underneath "Draw transparent textures last". On the command line, this is TextureOffsetFactor=<value>, where <value> is a decimal number between 1.0 and 10.0. The default value is 5.0.
(2019-10-25, 22:40)Travis Cobbs Wrote: [ -> ]Philo, I'm not sure what is up with your version. 4.3 was released at the end of January 2018, not the beginning of January 2017. I think you have a development version that I incorrectly labeled as 4.3. The official 4.3 version should have the "Draw transparent textures last" option in its Primitives preferences (as seen in Trevor's and Johann's screenshots).
One other thing. In case it wasn't clear, LPub3D is building LDView from source, and as such the LDView that it comes with is more recent than LDView's latest official release, which is version 4.3. There are some problems that I believe that I introduced since 4.3 that I am still trying to track down and fix before releasing version 4.4.
(2019-10-25, 22:40)Travis Cobbs Wrote: [ -> ]Philo, I'm not sure what is up with your version. 4.3 was released at the end of January 2018, not the beginning of January 2017. I think you have a development version that I incorrectly labeled as 4.3. The official 4.3 version should have the "Draw transparent textures last" option in its Primitives preferences (as seen in Trevor's and Johann's screenshots).
Yes, my bad. At the time I updated another computer but apparently not this one! What fooled me is that when I wanted to check, I googled LDView... and stumbled on the old Sourceforge page with only 4.2 version! It would be a very good thing to place a note there directing to Github page (which appears in Google results too, but only in 5th or 6th place!).
Upgraded now, works perfectly!
(2019-10-25, 19:41)Trevor Sandy Wrote: [ -> ]but I'm not sure LeoCAD will correctly apply the texmap.
LeoCAD was one of the first editor to support texmap, so there's good hope!