Wed, Dec 11, 11:08 PM CST

Renderosity Forums / Poser - OFFICIAL



Welcome to the Poser - OFFICIAL Forum

Forum Coordinators: RedPhantom

Poser - OFFICIAL F.A.Q (Last Updated: 2024 Dec 11 2:52 am)



Subject: Problems w/ normals or 2-sided polys


deci6el ( ) posted Mon, 10 March 2003 at 7:38 PM ยท edited Wed, 11 December 2024 at 10:52 PM

The setup: I make a model (a bowl) with one sided polys, all the normals facing in. Export as an obj. Bring it into Poser Pro Pack (Mac). It all looks fantastic. I have a self contained seamless room in which to put my poser people. I render an image, it all works. The problem: I render an animation. Now the bowl renders as a solid from the outside, as if the polys were double sided or the normals got flipped. The question: Is there a place in poser where I can set or check to make sure that Poser is not adding another side to my polys? Thanks to whoever wants to share their brilliance. And sorry if this is an old question. deci6el


Little_Dragon ( ) posted Mon, 10 March 2003 at 8:32 PM

Poser 5 has a render option to remove (or cull) backfacing polygons. It isn't perfect, however.

In older versions (including Pro Pack), you're completely out of luck. Poser will always render the backside of the polygons. You'll just have make sure the camera is completely inside the bowl.



BeatYourSoul ( ) posted Mon, 10 March 2003 at 8:47 PM

It isn't perfect? That's pretty sad. As a long-time 3D programmer, I'd have to say from experience that backface culling is the EASIEST thing to do, ever, in 3D graphics (if the polygon's normal is at an angle greater than 90 degrees from the camera LOS, it's culled). It takes a simple, well-known, very well-documented algorithm to do it correctly every single time. How could they screw that up? If they want, I have a book from 1988 that explains really simply with C code. ;0) BYS


Little_Dragon ( ) posted Mon, 10 March 2003 at 9:07 PM

In all honesty, the fault may be in the model that I tested it on. Or perhaps not. I had some very strange results with backface cull when I also enabled smoothing.



BeatYourSoul ( ) posted Mon, 10 March 2003 at 10:33 PM

Smoothing does add a level of complexity since backface culling is mainly restricted to flat, unaltered polygons, but in the display and render engine, this should be done prior to smoothing (or other polygon interpolations, such as Phong et al). The basic process is: 1. Transform objects into world space (build the scene) 2. Transform into view space (build the camera view) 3. Object level cull (stuff outside of view frustrum) 4. Backface cull remaining objects 5. Clip remaining stuff against view frustrum 6. Project onto view plane (convert 3D pts into 2D) 7. Render If their smoothing is being done before step 4., that could cause some grief. Question is how smoothing is implemented. If it involves polygon subdivision, then backface culling still works in either case. If it's a form of Phong interpolation, it should really occur at step 7.. One would hope that they do smoothing only during step 7. (?). BYS


Roy G ( ) posted Tue, 11 March 2003 at 12:55 PM

Didn't Curious Labs lay off most of their programming staff and beta testers? If these kinds of problems got through when they had a full staff, how are they ever going to fix them now?


ronstuff ( ) posted Tue, 11 March 2003 at 4:23 PM

I am assuming that you have created some kind of dome over the Poser scene, and are rendering from within the dome. You have to be very careful when doing this, because you can't rely on the "preview" window to give an accurate impression of how it will render. Be sure all your lights are "under" the dome and that you set the dome itself to NOT cast shadows. Also be sure that your camera (the one that is actually used in the animation - not just the "main" camera - is actually INSIDE the dome (not just with the lens zoomed into your scene, but physically inside the dome). Should render fine. Don't thihnk it has anything to do with backfaces or smoothing, but concave polygons might be another problem with the animation renderer.


deci6el ( ) posted Tue, 11 March 2003 at 4:53 PM

Thanks for the replies from everyone, sadly the moment you invoke the Poser5 context I am SOL because, as stated, I'm on a Mac. Ronstuff, thanks for a more direct look at how I might solve my problem, other than buying a PC, upgrading to P5, learning C! : ) Yes, can't rely on preview. Yes, "the bowl" does NOT cast shadows. Yes, the camara is inside and not just zoomed in. I will have to see about the lights being inside. What seems odd about the whole thing is that rendering a single frame achieves the desired result. Rendering an animation does not. I have yet to try rendering the animation out as a series of frames, maybe "tricking it" and later compiling them into a movie. Thanks again to all for taking the time to reply. deci6el


ronstuff ( ) posted Tue, 11 March 2003 at 9:31 PM

I know that concave surfaces can sometimes create unexpected results even if everything else is set right - just as a test - since you have already invested a lot of time, so why not a bit more - as a test try selecting the dome, using the grouping tool to reverse the normals, and try rendering a few frames. I would be interessted in whether this "backward" approach would slove the problem. - let us know how it turns out - good luck.


deci6el ( ) posted Thu, 13 March 2003 at 6:24 PM

Never render outside the box, seems to be the moral to this story. Any kind of intersection with "the bowl" and the camara or going outside of the bowl/cyclorama rendered outside polys. The grouping tool did not help. Until culling backfaces is available for Poser on the Mac I will just have to be careful about staying on the inside. Thanks for the help and the interest. deci6el


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.