Lit/Culled 3d objects

Started by jaymzjulian, August 06, 2020, 11:25:11 AM

Previous topic - Next topic

jaymzjulian

So I was playingh aroundw ith ways to reduce my draw load, and I kind of fell back to some experiements I did a while ago about culling - the problem at the time being, gsbasic isn't fast enough to really do what I needed without me running out of cycles.

But then I had the idea to use kmeans clustering to quantize the normals to a smaller number - 6, in the case of the demo presented here - and do the culling and lighting on larger sets of polys instead.  Shockingly, this actually works out.  So the procedure ends up being:

a) Generate a set of lines and normals via "some mechanism" (I have a couple of mechanisms for this, one of which involves blender, and one of which involves generating the normals from the lines assuming the objects are vaugely built arounda center)
b) Reduce these set of normals to clusters - I'm using python's sklearn.cluster.KMeans for that!
c) in gsbasic, use vectorrotate and friends to transform the normal set - of course, you need to do the world translate/rotate as well - i.e. consider the camera!  But that's well within the realms of achievable now....

So you end up with an array of objects which happen to mesh together.  There is a couple of serious downsides this this technique, mind you:

a) because the objects aren't linked anymore, there is extra ReturnToOrigin() calls!  indeed, drawing this tree returns to origin 6 times..... we can't easily avoid this, because even if we did relative pen movement things, we don't know if part of the obhect will be drawn until the math is done!
b) things do look better if your object is made of polys rather than lines at the outset, however then you have double-draw issues.  Blender is actually really good at creating normals that don't suffer this, mind you.... essentially if you have "smooth" point normals (as are genearted by the smooth object modifier), it works out well, whereas if you have "flat" surface normals, it doens't work out so well unless you double draw edges, defeating the point of what we're trying to do here.  Of course, there is no reason NOT to smooth your normals when the object isn't filled, so..... it actually doens't matter as much as you'd think... (after all, there is no fill, hence no gouroud shading/phong shading to deal with!)


So you end up with the attached demo.  I did also attach the python I use to generate that set - it's inputs are kind of very specific, though, it's absolutely not yet a generic tool, but i figured the technique was at least worth sharing!

Vectrex32