🔒 Locked

Software occlusion map rendering...

Started by Freaky Apr 18, 2004 at 3:05 PM 13 replies 1.8k views

Original Post

Freaky

Apr 18, 2004 at 3:05 PM

I am currently thinking about implementing occlusion mapping Yann style

Basically meaning that my GPU is rendering the actual scenery and the CPU is rendering my occlusion map for the next frame in software mode. The CPU will be rendering simplified models from the original scenery. The occlusion meshes. The problem is that my experience with software renderers is completely zero so a new era of learning will come

Since i'm using OpenGL for the engine itself I understand that my software pipeline should mimick the OGL pipeline. My current idea is: - Pass a list of primitives to my software renderer. - For each vertex: - Multiply the vertex coords with the modelview matrix - Then multiply with my projection matrix - Apply perspective division (device normalized coords) - Doing the viewport transformation - For each triangle - Draw the triangle's Z coords by interpolating - We will interpolate the coords calculated per vertex above At the end of this shit I should have a buffer (occlusion map) filled with Z coords of the nearest occluders. During rendering I will check my bounding box in this buffer. If the bounding box is behind the z coords in the buffer then the object isn't visible and won't be added to the rendering queue. Otherwise it will be added. Is this a viable idea? If not, please give me any comments/feedback you can whip up

Questions come to mind: 1.) When software rendering, is it advisible to do polygon batching? Or would passing each occlusion mesh seperately be more effecient. I imagine the call overhead won't kill anyone and no bus transfers are to be made. I don't think batching would be of any use to a software renderer but I could be wrong here. 2.) Does anyone have any tutorials/resources on writing a OGL compliant software rasterizer or does anyone have some source for me to look through? If so, please let me know by mail. - Freaky [edited by - Freaky on April 18, 2004 4:09:12 PM] [edited by - Freaky on April 18, 2004 4:09:39 PM]

technobot

Apr 18, 2004 at 5:41 PM

quote:
Original post by Freaky
Since i''m using OpenGL for the engine itself I understand that my software pipeline should mimick the OGL pipeline.

My current idea is: [...]

It doesn''t matter how you pass the geometry to the software renderer, what is important is that the transformation and rasterization of that geometry is done exactly as specified in the OpenGL specification. Otherwise, your occlusion maps won''t match what you get on screen.

quote:

During rendering I will check my bounding box in this buffer. If the bounding box is behind the z coords in the buffer then the object isn''t visible and won''t be added to the rendering queue. Otherwise it will be added.

This is correct. But remember - checking the corners alone is not enough, since the middle may not be occluded. You have to transform and rasterize the bounding box just like you do with normal geometry, except that you won''t be updating the occlusion map while doing this.

quote:

Questions come to mind:

1.) When software rendering, is it advisible to do polygon batching? Or would passing each occlusion mesh seperately be more effecient. I imagine the call overhead won''t kill anyone and no bus transfers are to be made. I don''t think batching would be of any use to a software renderer but I could be wrong here.

2.) Does anyone have any tutorials/resources on writing a OGL compliant software rasterizer or does anyone have some source for me to look through? If so, please let me know by mail.

1. Since you''re only interested in the z coordinates of each pixel, you can simply send a list of all the vertices of all the occlusion meshes within the view frustum. Or you can send them one mesh at a time. Personally, I prefer the former. But this will only work if all the vertices define the same type of primitive (e.g. glTriangles).
2. First of all, download the OpenGL specification from opengl.org. Then, google for software rendering tutorials as necessary.

Michael K.,
Co-designer and Graphics Programmer of "The Keepers"

We come in peace... surrender or die!

sBibi

Apr 18, 2004 at 6:16 PM

quote:
This is correct. But remember - checking the corners alone is not enough, since the middle may not be occluded. You have to transform and rasterize the bounding box just like you do with normal geometry, except that you won't be updating the occlusion map while doing this.

you'll have 12 tris to render, and in the worst case 6 tris to rasterize if you do backface culling.
you can simply project the 8 vertices, and get their bounding rectangle. you only need to render a 2D axis aligned rectangle, witch is damn faster than rendering the bb.
but depending on the object, it might get too conservative. works quite well with me though...
or if you can have the luxury to have a simple bounding volume (not necessarily convex) that approximates better the occlusion of the object than a bb, and then project the vertices and get their 2D bounding rect, it's much better. (but slower too if there are too many verts)

quote:
I imagine the call overhead won't kill anyone and no bus transfers are to be made.

I don't think your bottlenecks will be here for the moment

EDIT:

quote:
Does anyone have any tutorials/resources on writing a OGL compliant software rasterizer or does anyone have some source for me to look through? If so, please let me know by mail.

I've got an SSE "optimized" occlusion culler that uses HOMs (YannL style too

) if you want an example.
(optimized is between double quotes because I learned SSE for this occlusion culler so it might not be very good asm, but it works, and faster than the non-sse version)
tell me if you're interested, I'll email it to you, np

[edited by - sBibi on April 18, 2004 7:22:45 PM]

particleG

Apr 18, 2004 at 7:01 PM

EDIT: Thanks for the code

[edited by - particleG on April 19, 2004 12:27:35 PM]

transformation

Apr 18, 2004 at 9:19 PM

quote:
Original post by sBibi

I''ve got an SSE "optimized" occlusion culler that uses HOMs (YannL style too ) if you want an example.
(optimized is between double quotes because I learned SSE for this occlusion culler so it might not be very good asm, but it works, and faster than the non-sse version)
tell me if you''re interested, I''ll email it to you, np

[edited by - sBibi on April 18, 2004 7:22:45 PM]

Could I please please please get that too. I''d really appreciate it.

transistic@msn.com

osh

Apr 19, 2004 at 4:47 AM

Not so long ago I was coding the same thing. Check out this post. You can find my software rasterizer func code there. And I turned it to occlusion buffer then (perhaps I can provide you that code).

Muhammad Haggag

156

Muhammad Haggag

Apr 19, 2004 at 7:07 AM

quote:
Original post by sBibi
I''ve got an SSE "optimized" occlusion culler that uses HOMs (YannL style too ) if you want an example.
(optimized is between double quotes because I learned SSE for this occlusion culler so it might not be very good asm, but it works, and faster than the non-sse version)
tell me if you''re interested, I''ll email it to you, np

I, too, would be interested

Seems that due to popular demand, you''ll need to put it in some webspace. However, if you don''t, my email is MHaggag at optimize-eg dot com.

Muhammad Haggag,
Optimize
Bitwise account: MHaggag -

overnhet

Apr 19, 2004 at 10:37 AM

sBibi : is this your webpage ? Your trinity engine looks great, is it still under development ?

Toni Petrina

Apr 19, 2004 at 12:41 PM

quote:
Original post by sBibi I''ve got an SSE "optimized" occlusion culler that uses HOMs (YannL style too ) if you want an example.
(optimized is between double quotes because I learned SSE for this occlusion culler so it might not be very good asm, but it works, and faster than the non-sse version)
tell me if you''re interested, I''ll email it to you, np

I am working with occlusion culling in DX9 and it is going nowhere.

I would be interested in that code sBibi. PLease, if you can e-mail it, i''d be greatful:-P

malyskolacek

Apr 19, 2004 at 2:57 PM

quote:

I''ve got an SSE "optimized" occlusion culler that uses HOMs (YannL style too ) if you want an example.
(optimized is between double quotes because I learned SSE for this occlusion culler so it might not be very good asm, but it works, and faster than the non-sse version)
tell me if you''re interested, I''ll email it to you, np

Could you please send the OC to me? (maca AT melco DOT cz)
I have been doing a similar thing recently and need some help with it.

I have also one question: Since I''m programming in D3D, where can I find the D3D pipeline specs? Or are D3D and OGL pipelines same?

technobot

Apr 19, 2004 at 3:12 PM

quote:
Original post by malyskolacek
I have also one question: Since I''m programming in D3D, where can I find the D3D pipeline specs? Or are D3D and OGL pipelines same?

Ehm.. not sure. Try msdn... My guess is that any OpenGL compliant graphics card would work the same with D3D. Doesn''t make much sence making two mutually exclusive pipelines.

Michael K.,
Co-designer and Graphics Programmer of "The Keepers"

We come in peace... surrender or die!

sBibi

Apr 19, 2004 at 6:35 PM

wow.. didn't imagine so many of you guys would be interested in some occlusion sample code...
already sent it to particleG and transformation, but maybe I'll post it here too...

quote:
sBibi : is this your webpage ? Your trinity engine looks great, is it still under development ?

thanks

uhm, yeah, this was... it's starting to get a bit old now, and no, it isn't under development any more. and if it doesn't look too bad, it's only because the original Q3 maps look quite good in the first place, that was a pretty basic renderer, with only a few Q3 shaders implemented. (there's a more complete software rendering version here btw..)

I uploaded a zip containing occ code here: http://www.epita.fr/~bilalt_j/hom.zip (currently down :/ don't know when it will come back, I'll try to upload it somewhere else tommorow if it hasn't been back online)
this is all C code btw...

(oh, and it will look horrible if you view it with non 8 space tabs... in fact you might find it horrible anyway ^^)
there are a few things I'm not happy at all with in this code, but I had to move on other stuff and didn't have time to really clean it and optimize it further. btw if you've got suggestions do not hesitate

[edited by - sBibi on April 19, 2004 7:37:03 PM]

Freaky

Author

Freaky

Apr 20, 2004 at 1:30 PM

sBibi, please check your email account

- Freaky

Toni Petrina

Apr 21, 2004 at 12:25 PM

sBibi
Thanks a lot.

benjamin bunny

144

benjamin bunny

Apr 21, 2004 at 10:41 PM

I used an occlusion mapping system as part of my final year project at uni. I'll probably put the paper up at some point. It's a pretty straightforward z-based SSE OM rasteriser which works in parallel with OpenGL, and it's very efficient compared to hw OM. Not sure how it would compare to Yann's method.

Computer graphics: principals and Practice 2nd Edition is an excellent book if you want to implement a software renderer. In fact, it's just an excellent book on CG, full stop.

[edited by - benjamin bunny on April 21, 2004 11:43:24 PM]

Topic Locked

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