Thu, Nov 28, 6:31 PM CST

Renderosity Forums / Poser - OFFICIAL



Welcome to the Poser - OFFICIAL Forum

Forum Coordinators: RedPhantom

Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 28 11:20 am)



Subject: "Decals" in Poser?


kuroyume0161 ( ) posted Sat, 18 October 2003 at 10:18 PM · edited Mon, 25 November 2024 at 3:35 AM

file_80673.jpg

I have an object with one polygon with a separate material that represents a decal, an area which can be changed to different symbols independently of the other material. This has transparency and a separate bump than the other material. Although the transparency works to get the "under color" through, I donot know how to get the other material's bump through the transparent area of the decal material (without creating a bump map for each decal). Any ideas. Here's an image to give you an idea about what I'm talking. Thanks, Kuroyume

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


Mason ( ) posted Sat, 18 October 2003 at 10:30 PM

Well if you have P5 you can use the material color math multiply. You can add the two bump maps together by setting to color for each color_math channel to white, point the channel;s to each bump then set the operation to multiply. That's one way. Another way is to make use of the bump and gradient bump channels. Put one bump on one channel and the other on the other channel. A more elaborate way is to use the color_math and the transmap with multiply to cut the medallion portion from the medallion map then use the inverse of the transmap to cut the non-medallion portion from the other map. Then add the two together.


kuroyume0161 ( ) posted Sat, 18 October 2003 at 11:01 PM

Ah. I'll have to try the first method. The second method doesn't seem to work on the gradient bump channel. Is the gradient inverted for that channel or something?

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


kuroyume0161 ( ) posted Sun, 19 October 2003 at 12:00 AM

file_80674.jpg

The first method works well. But, I have this problem remaining (see image). This is Firefly and is worse in the P4 renderer. Now, this junk does not show in the modeling program (in render, polygons, or UVs) with a color test map. Nor does it show in UV Mapper with its color test map. Nor does it show up until I add the bump map in Poser. The bump map is just blurred noise from Photoshop that covers the entire UV space - no seams or breaks or shifts. I have "split vertices" in UV Mapper, but either way, this junk shows up. Any clues?

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


Mason ( ) posted Sun, 19 October 2003 at 2:29 AM

you mean the slanted and vertical line on the surface is the junk? That looks like you didn't weld vertices correctly so the geometry has a tiny gap in it.


Mazak ( ) posted Sun, 19 October 2003 at 4:43 AM

Deactivate 'smooth polygons' for the prop. Mazak

Google+ Bodo Nittel 


kuroyume0161 ( ) posted Sun, 19 October 2003 at 9:55 AM

file_80675.jpg

I've deactivated 'smooth polygons' and 'welding identical vertices' not only does not remove the problem, but introduces worse ones. Already checked. There are no identical vertices prior to import. There are no "tiny gaps"; this part of the object was modeled from a subdivided cube, the indent booleaned into it. It would be impossible for any gaps to exist if there are no spurious vertices. Let me show you a P4 renderer render from a different angle. The extent and location seems to change with it. Note the two parallel disturbances near the middle. These aren't polygons - they represent to edges of the "decal" polygon. Edges, mind you.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


kuroyume0161 ( ) posted Sun, 19 October 2003 at 9:56 AM

file_80676.jpg

Now, here's a Firefly render from the same direction.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


Mason ( ) posted Sun, 19 October 2003 at 6:53 PM

It could be you have a face underneath that's popping through? Another thing could be that the UV mapping is somehow messed up. That actually looks like some kind of degenerate polygon. Did you use a boolean to cut the hole in the surface? If so you may need to reduce the mesh to an editbale mesh if you did this in max. That crap maybe due to how you cut that hole in the surface. Infact, come to think of it, those lines look like edges in the geometry created from a boolean cut. it could be you have to go in and find those small edges and remove them.


kuroyume0161 ( ) posted Sun, 19 October 2003 at 8:03 PM

I've checked and double checked the geometry. There are no multiple vertices and no degenerate/flipped/other polygons than what are seen. I personally did the UV mapping myself with my own hands! It is NOT messed up. I know how to UV map. ;) That is exactly why this is disconcerting. In C4D, BP, and UV Mapper, the test map is flawless, so flawless that I was lulled into a sense of security about importing into Poser (ah, Poser). This was done in C4D R8. Yes, I did use a boolean to cut the divet into the surface, but these artifacts show up elsewhere where no booleans or other fancy things were used (the image before last at the top right, for instance). Extruded Bezier splines in those cases, all made into polygonal geometry and optimized. Now, since R8 does handle edges, I will check to see if there are any existing that shouldn't, but the doubt is great. Again, none of this shows up in C4D, BP, or UVMapper, only in Poser (ah, Poser). After reading up a bit in a search, this could be caused by very thin polygons (not degenerate) which are 'degenerated' by the scaling into Poser. There isn't much I can do about this without going over the entire model and UVs. If you'd like, I post a mesh to get an idea of the layout.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


kuroyume0161 ( ) posted Sun, 19 October 2003 at 8:21 PM

One more thing! This ONLY shows up in the bump map. Disconnecting the bump map image from the Bump channel and connecting to the Diffuse_Color channel removes the artifacting altogether. This has nothing to do "directly" with the model, but is only caused by the structure thereof.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


Mason ( ) posted Sun, 19 October 2003 at 8:22 PM

Does it show up if you don't use a bump map? Does it show up if you render flat colored?


kuroyume0161 ( ) posted Sun, 19 October 2003 at 10:05 PM

No, it does not in response to both. But I think that the solution is found. I unplugged the bump map from the Bump channel and plugged it into the Gradient Bump channel and, alas, all of those nasty artifacts disappeared. I thought that I had heard something of this previously, but a search returned nothing of it. This information should be made more readily available - Do not use Bump, use Gradient Bump instead... There will be more questions in the future, as this is not even near completion. It must be turned into a partless, boneless figure so that it can take MAT Poses. So, it will be interesting. Thanks for the help and wish me less strange troubles.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.