DRD Team

Do you have some code I could use? I see no point reinventing the wheel by doing it myself.

dpJudas wrote:finally some way to flag geometry not to be included in ssao.

I think the best would be a texture flag, rather than a geometry flag. With a keyword in GLDEFS to mark a texture as a sky texture. That'd solve the issue with sector-based skyboxes.

ibm5155 wrote:what about using Marching Cubes on the fly for converting voxels models in a polygonal 3D model?
It could generate quite good 3D models like:

(a) segmented volume of interest—voxel mesh, (b) surface mesh generated from marching cubes algorithm (no interpolation), (c) rendered view of surface mesh generated from marching cubes algorithm (including partial volume-based interpolation).

That bone is kind of high-res. How would it look like with a low-res item, like one of the Doom Voxel Project's pickups?

A university student did indeed program this, and made his work available to use.

However, he has listed no license requirements. He does have a contact page, however.

His site is dated past 2 years, so let's hope he hasn't just graduated and forgotten about it.

The code for the marching cubes is here (http://paulbourke.net/geometry/polygoni ... source.cpp) (public domain) and http://paulbourke.net/geometry/polygonise/
and from the Eruanna link https://graphics.stanford.edu/~mdfisher ... Cubes.html ...

You can test it with MagicVoxel https://voxel.codeplex.com/ and exporting the voxel with the "MC" button and view the images with (hmm idk, the 3d printer app from Windows 10 could view the models)
Here are some models from voxel to polygons using marching cubes:





Shall I spoiler the images?

Gez wrote:I think the best would be a texture flag, rather than a geometry flag. With a keyword in GLDEFS to mark a texture as a sky texture. That'd solve the issue with sector-based skyboxes.

Hmm yes, that might be good way of dealing with it. I don't think I can think of a situation where you'd want a specific texture to be subject to SSAO in one situation and not in another.

For skyboxes there's already a sector type which I implemented for BoA. If a sky viewpoint is found within such a sector it should be treated like a regular sky.
I'm not even sure if it's a good idea to do SSAO for a sky viewpoint at all. Most of the time the scale will be completely off, totally exaggerating the effect.

I can see what you are saying there, Graf, but I do disagree a bit. Even mountains have ambient occlusion from miles/kilometers off, it's just not as obvious unless you look at them a little more carefully. It can be seen particularly with cuts in rocks (for example, the Rocky Mountain range in the United States - from which you can see the Flatirons from Boulder County). Basically, ambient occlusion is nothing more than shadows that are not directly cast by an object between a point and the light source - and obviously, bigger objects create bigger shadows. Size is completely relative. You can get a miniature model and if it's made with the same material, it will look just the same when the sun is cast upon it in the same direction.

Apologies for the large image:

Yes, but I somehow doubt that a postprocessing pass with no actual info on what it processes can detect that any object in a skybox is on a 1:10 scale, for example. This will require some testing before making a decision. I was more thinking about some of the first generation skyboxes which are just a square around the viewer with a single texture on each wall.

True - those need no SSAO.

Hence my suggested flagging of textures. Take Kristian Aro's recent release of Plutonium Sandpit, which uses an old-style skybox, and you could mark the SKYBOX1A/B/C/D/F/G textures to be skies.