POV-Ray : Newsgroups : povray.binaries.images : Saving PovRay objects as geometry : Re: Saving PovRay objects as geometry Server Time
11 May 2024 15:19:37 EDT (-0400)
  Re: Saving PovRay objects as geometry  
From: Patrick Elliott
Date: 25 Oct 2011 23:16:30
Message: <4ea77b8e$1@news.povray.org>
On 10/25/2011 1:42 PM, clipka wrote:
> Am 25.10.2011 21:51, schrieb H. Karsten:
>
>> I'm wondering that your code did not find it's way into the regular
>> PovRay! As
>> well, I was asking for micro-poly-displacement in PovRay already long
>> time ago,
>> and nobody could get me some help..
>>
>> A lot of good Ideas are still not part of PovRay. Only available as
>> patches.
>> This is one of the most disadvantages of PovRay ever!
>
> There are a few reasons contributing to this:
>
> * Including a 3rd-party patch into POV-Ray proper requires the patch to
> be fairly stable, and play well with POV-Ray's traditional features.
> (MC-Pov, for instance, doesn't; for example you can't use both MC-Pov's
> features and conventional light sources at the same time, and MC-Pov's
> diffuse illumination gives significantly different results than
> radiosity due to an error in MC-Pov's math.)
>
> * Including a 3rd-party patch into POV-Ray proper requires some member
> of the dev team to "adopt" the feature for future maintenance (or the
> 3rd-party author to credibly commit themselves to future maintenance of
> the feature as part of POV-Ray proper).
>
> * Including a 3rd-party patch into POV-Ray proper requires the patch to
> be compatible with the internal architecture of whatever POV-Ray version
> is currently "in the making"; this is especially a problem with the
> transition from 3.6 to 3.7, which not only changed major portions of the
> architecture, but also took quite a lot of time.
>
> * Including a 3rd-party patch into POV-Ray proper requires the dev team
> to feel that the patch would make a good addition to POV-Ray's portfolio
> of features, without adding too much overhead in case the feature isn't
> used.

Still, its the only case I have seen of something that kind of manages 
something I wish I could do. I am looking at a situation where:

1. I am not too good at texture, but OK at building, so a lot of the 
"detail" would be easier to do by adding parts, rather than texturing.

2. I need it to be in a form that can be imported to something that 
isn't POV-Ray.

3. Some sort of "level of detail" trick would be nice to have.

The perfect way to do this, as I see it, would be to have something like 
this trace. You generate 3 levels of detail, limiting the amount of 
geometry you create. You use object patterns, or the like, to generate 
the texture. I.e., you convert geometry that falls outside the bounds of 
the level of detail you want into object pattern, so you still get the 
same "detail", but its mapped to the object texture, not actual mesh detail.

You can "sort of" get LOD in other applications, you have to do it 
manually, and you can't "map" the missing geometry onto the simpler 
model. And, for course, the smallest levels of detail have to be an 
image, since you can't project those tiny details into a UV mapped image 
directly (or even, if supported, shadow maps, plus image). For someone 
like me, it would be brilliant if this sort of thing was more direct. 
But, even without it, it would still be bloody nice to build using 
primitives, and have the program generate a final mesh, which removes 
all the bits I don't need. Easy to do, automatically, via POV-Ray, since 
it uses CSG. A bloody pain in the ass in all those "super duper powerful 
mesh editors". lol And, as far as I know, no one has even attempted what 
I describe above.

I am not looking forward to trying to do it the harder way. :p


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.