Fri, Jan 24, 5:13 PM CST

Renderosity Forums / Poser Technical



Welcome to the Poser Technical Forum

Forum Moderators: Staff

Poser Technical F.A.Q (Last Updated: 2024 Dec 04 2:47 am)

Welcome to the Poser Technical Forum.

Where computer nerds can Pull out their slide rules and not get laughed at. Pocket protectors are not required. ;-)

This is the place you come to ask questions and share new ideas about using the internal file structure of Poser to push the program past it's normal limits.

New users are encouraged to read the FAQ sections here and on the Poser forum before asking questions.



Checkout the Renderosity MarketPlace - Your source for digital art content!



Subject: WTF?!? Weird blackouts...


_dodger ( ) posted Fri, 29 November 2002 at 1:52 PM · edited Mon, 05 August 2024 at 7:14 AM

file_33784.jpg

Okay, I'm trying to upgrade my standard flame format with an InnerFire cone to make it renderable properly at above-angles. The cone is 12 vertices diameter and 4 vertices up and down for a grand total of 37 vertices. Simple enough, right? Except when I render it, this happens. Now I know that sometimes thin triangles (these aren't that thin, it's only 12 sides, which leaves them rather not-thin IMHO) will do this weird 'blackout' effect, though I have no clue why this ever happens. But here's the *really* annoying part -- why doesn't this happen with the default P4 cone prop? It has even more and thinner triangles in it and doesn't have this problem. Is there a fix (there has to be since the P4 cone works)? What is it? How do I avoid having to rebuild this from scratch? How do I avoid having to rebuild all 24 of my flicker MTs from scratch, too? This is bloody ridiculous.


_dodger ( ) posted Fri, 29 November 2002 at 1:53 PM

Just as note -- if I trans-out the entire innerFire material with no_map and just set it 100% min 100% max falloff 0, the entire inner fire cone becomes invisble as it should EXCEPT for this part!


_dodger ( ) posted Fri, 29 November 2002 at 1:59 PM

file_33785.jpg

If it helps, here's the UVmap of the mesh.


_dodger ( ) posted Fri, 29 November 2002 at 2:00 PM

My bad, 49 vertices.


_dodger ( ) posted Fri, 29 November 2002 at 2:42 PM

Ahh, I fixed it. Seems Split Vertices in UVMapper took care of this.


_dodger ( ) posted Fri, 29 November 2002 at 2:44 PM

file_33786.jpg


lesbentley ( ) posted Fri, 29 November 2002 at 3:09 PM

The flame looks great.


_dodger ( ) posted Fri, 29 November 2002 at 5:05 PM

Yeah. Now I'm encountering problems with the gravity thing... wherein the JPs are acting really flaky with the point-at. I think I'm going to have to scratch the reversed polarity idea since this is done as a figure, not a floating prop. Instead I'll have to make an Anti-Gravity Well just the same but up in the sky at max distance. sigh


_dodger ( ) posted Fri, 29 November 2002 at 5:07 PM

Or maybe not. I got one working but it's not making the Gravity Well visible in the menu, like you were having the problem with. The one I hacked out of a PZ3 is the one that's acting flaky, the one I hacked together first, though, seems to work fine. Except the fact that the gravity well is not visible anywhere at all even in the menu. I'm way confused.


_dodger ( ) posted Fri, 29 November 2002 at 5:22 PM

Oh, weirdness. In the one where I didn't get it in the menu -- here's why... it wasn't there. I found the syntax error -- I closed the main block before I got to the doc{block which means it stopped reading. So the result was that it never loaded the Gravity Well. I was Pointing-At a nonexstient actor. But it was working. Som I'm a little bit weirded out by that...


_dodger ( ) posted Fri, 29 November 2002 at 5:34 PM

Okay I just tried something really weird and it seems to be working... I removed the Gravity_Well prop entirely and it didn't work. That makes sense. Here's what doesn't... I then replaced the Gravity_Well declaration but didnt' add the prop at all. So the mostly empty declaration at the top was there (with only the geomResource and the storageOffset), and the other part where you set all the channels -- that isn't there. It's working, mostly. However, on y rotation of the handle at certain angles it forces the flame into an angle (and thus the two spotlights that are part of it). This is getting very strange. It's 'pointing-at' a prop that doesn't exist and has no parametres at all except what geometry to use and the storage offset. As a result, that prop that it's pointing at isn't there but it's pointing at it anyway. It's not only not there, but in not being there it's not able to be located in any place within the UNIVERSE either... but somehow the flame is pointing at it. I wonder if this would work just the same without the reversed endpoint and stuff (or better)


_dodger ( ) posted Fri, 29 November 2002 at 6:26 PM

It's the spotlights. For some reason the spotlights are screwing up the joints.


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.