Couldn’t you just send view rays from the camera and subdivide based on ray length when it hits something, since they would bounce off raymirror surfaces and bend from extreme refraction it could be possible to make it not glitchy.
Since view rays could go forever it would be wise to make an adjustable termination point after which there would be no subdividing.
ok, i tested now a scene with my script which i used earlier also together with qdune. let’s compare the results with similar subdivision settings (1 pixel/poly):
QDune:
render time: 1:40 minutes for 4,250,000 micropolygons
Micropoly Script:
render time: 6 minutes for 12,000,000 micropolygons
not bad for a python script. 
beside all the disadvantages in speed and memory, i think the best thing about this script is that you have all features of blenders renderer unlike qdune.
They look almost identicle:eek:
This really should be ported to C once this is perfected, perhaps Brecht or Ideasman can take care of that.
For me to possibly download I’ll wait until you make a bit of progress lowering the memory usage and speeding it up.
cool!
beautiful tests, im curious how this is gona turn out 
ok, i’ve found a nice way how to make sure edges only within the viewfield will be subdivided. it begins to become more complex but this saves a lot of memory which you now can use for more detail in higher resolutions.
i also had the idea to include an additional refinement var. this means you can have a higher pixel per poly factor (less detail) but compensate this by plain subdividing of the lowres micropoly meshes. that’s less accurate and costs a bit more memory (depends on how detailed your source meshes are) but since i’m using the hardcoded subdivide function it gives an enormous speed increase.
@Surt:
i have included a switch to improve the banding problem but interpolation would be a bit to much for this script because it would become unusable slow.
@Cyborg Dragon:
raytracing via python is probably no good idea. :no:
i’ll add a switch to disable the viewfield optimization if you need mirrors in your scene, that’s certainly faster.
UNBELIEVABLE!!!
i mean, your speed of improving this script. i was just preparing a mockup and you beat me
by already implementing the idea, hehe… nice work!
can we have a before/after memory consumption comparison? thanks
[edit: linked image has been taken down, gg]
thank you, i appreciate your try to help.
a direct comparison is difficult because i did many changes in how the algorithms work. but i can say that the last example in the start post needs now only 30 seconds instead of 2:30 and uses around 250 mb memory instead of 1 gig. it has even a better visual quality (less banding).
here is the proof, i allow you a look at my desktop 
(core 2 duo 1,6 GHz):
dude, you rule. no, seriously! :ba:
simply amazing. Kai I think coding the demolition script has taught you even more than you already knew before. Especially with optimisation.
Heya, that’s really cool! It’s not what’s usually referred to by micropoly rendering, rather it’s a form of adaptive subdivision, which is still very cool, and would be a great addition. I’ve also seen in other apps, the ability to subdivide not just based on the distance to the camera, but also based on the detail in the displacement map. i.e. large areas of solid colours won’t get subdivided much, but areas of high contrast will.
WOW! This is shaping up very nicely!
That’s a more eloquent version of what I was getting at a few posts back!
Shame about reflections though!
Good thing would be to check for curvature/angle between polys of the resulting displaced mesh (which somehow includes what broken says plus the curvature of the underlying basemesh) and then have a threshold angle [only subdivide edges when angle > 5° or something along these lines].
This looks absolutely great. Matt’s suggestion about subdivision based on contrast and details also would be really a great add-on.
hey, are you interested in porting this to C? - Subsurf could be extended to support adaptive subdivision.
Probably the easiest way to start would be to write as a separate modifier, then merge it with subsurf.
yeah, i just implemented my idea of how micropolygons work. i didn’t knew too much about internals of reyes and stuff, i just coded my imagination of it in simple math.
also such kind of surface optimization sounds like a big waste of CPU resources only to save some memory. it’s like applying the decimate modifier to a million poly mesh. if you have ever tried this you know what i mean. 
i could imagine that it’s even difficult when using animated textures because of polygons popping around and such effects. i would say i prefer to keep it as simple and fast as possible.
@Ideasman:
i’d like to give it a try. shouldn’t be to hard because i know c. i have written a voxel engine for a calculator a few years ago.
i know c. i have written a voxel engine for a calculator a few years ago.
Hah Hah! you could port that to blender too!
it would probably not satisfy the blenderheads expectations in visual quality… but on the other hand it needed only 160 k ram and 10 MHz to run properly. 
hey guys! you’re doin great…
am really no coder, but how do you think other apps are able to have micropoly rendering way ahead of blender? well…aside from fundings considering we have very talented coding community.
How it works with texture coordinates?
I mean,it can be used with uv mapped subsurf?
It could be useful for displaced/sculpted characters.
Btw it’s really promising.
Kai, there are people quite interested in Voxels for Blender just check this tread:
http://blenderartists.org/forum/showthread.php?t=119283
I’m sure they/we would be really glad to see voxels implemented.
Anyway, you implementation of Micropoly’s is looking really great.
But do polygons really have to be created before they can be rendered, or is it also possible to view the low resolution in the viewport and have the high detail rendered ? (did i explain that correctly ?)
@Garuhhh, Micropolygons isnt brand new, the idea is a few years old (1987 to be exact) so other programs have had more then enough time to implement it.
just think of all the other technology that has been invented… but not implemented in applications.
Ofcourse it also has to do with what an application’s focus is, as blender is getting more advanced… so are it’s features.
