Skip to main content
gamedev.net
🔒 Locked

Alpha mesh solution?

Started by NotTaxes Oct 10, 2002 at 3:21 PM 0 replies 650+ views
Original Post
NotTaxes
NotTaxes
I while ago I posted a question to do with complex meshes having some of their subsets rendered with a semi-transparent texture - if other objects got placed inside the mesh, but rendered later on in the pipeline, the alpha bit was basically ignored effectively you couldn''t ''see'' through the windows. The thing is that I have a lot of different types of transparent things (I''ve got billboards, glass windows, particle effects... and some planar mesh features that rely on transparencies). To solve the problem for all of these various things, I am thinking of doing something like this: //Main Loop Declare an empty Cache RenderAllMeshes If a subset of a mesh has a transparent texture, don''t render the subset, but add its Type, Mesh, Position, Rotation and scale to the Cache. Update all billboards and add their Type, Texture, Position, Rotation and scale to the Cache Update all particles and add their Type, Texture, Position, Rotation and scale to the Cache Sort the Cache from Back To Front relative to the camera. For each Cache Entry, Check the type of entry (Mesh Subset/Particle/BB) and render it through the appropriate method. Anyway, I figure that this will work. I am already using the cache thing to handle Billboards and particles, so adding in mesh subsets as a type is no biggie. But, I am concerned that the re-rendering of mesh-subsets, with all those world transforms and stuff, will slow the code down too much. I could sort the entire mesh by depth, but there are issues with that, because contained objects would still get occluded. Does this seem like a worthwhile way forward, or is there a better way?
'Doing the impossible is kind of fun' - Walt Disney
dedrick
dedrick
it''d be even better if you could guarentee that the subsets are all translucent or all opaque.

for the normal pass, use zwriting and z checking, for the alpha pass, use zchecking with zwriting off. but you probably already figured that part out.

as for sorting the mesh sections from back to front and rendering them, for the totally correct result, the sorting should be done at the poly level. prefereably with splitting.

if the subsections are convex, you don''t have to worry about this - render the backfacing ones first, then the front facing ones.

but to answer your question, as long as your pipeline is well balanced and you''re sending more than a dozen polys down with each draw primitive call, you should be fine.

as always, the best thing to do is get the thing working, the profile it. in my experience, most of the time, what you think is goign to take most of the cpu time doesn''t.

dedrickwww.whiteknucklegames.com

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.