 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Renderman is using scanline rendering techniques, this has nothing to do
> here.
Renderman is an interface, not an implementation, so it is not using any
rendering techniques at all. There are a lot of Renderman
implementations that use ray-tracing.
The REYES algorithm "dices" the primitives into a micropolygon grid -
POV-Ray tesselates into a triangle mesh (I am talking about bicubic
patches only - and I assume that, if they'll be implemented somday,
NURBS and SDS will work the same way).
So there's no real difference in how parametric surfaces are being handled.
REYES applies displacement to the micropolygon grid, and POV-Ray could
apply displacements to the tesselated triangle mesh.
> And there of course is no self shadowing in the image you used as
> example.
That's right... bad example. But it would slef shadow if shadows were
turned on :-)
> I'd suggest you reread what i wrote. This remark shows you have
> completely misunderstood it.
Hmmm...
Christoph Hormann wrote:
>Why would you want to do this if it is a mesh anyway and you could
>displace the mesh (any mesh, not just patches)?
Reread. Maybe I misunderstand. How would you displace a nurbs or patch mesh?
>What would be interesting is support for adaptive render time
>subdivision of meshes with displacement.
That's exactly what I was trying to say - sorry if the term
"tesselating" was wrong (I'm not a native english speaker), still I feel
that it is more correct than "subdivision". You can subdivide a polygon
mesh to get a finer polygon-mesh (that's how SDS works), but subdividing
a patch will only yield more patches...
-Sascha
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You are mixing things here that don't belong together and that's also
the source of your misunderstanding. Try first to understand the terms
you are using here and you will see that it does not make sense.
To sum it up:
- it does not make any sense to add a displacement mapping feature to
any higher level shape in POV-Ray that is internally rendered as a mesh.
- it is not possible to add a displacement feature to any shape POV-Ray
renders analytically.
==> the only shape that could profit from a displacement mapping feature
is the mesh but apart from render time subdivision with displacement
this is already possible to implement in SDL (or external programs).
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmx de> wrote:
> - it is not possible to add a displacement feature to any shape POV-Ray
> renders analytically.
Change "possible" to "efficient" and then you may be right. (And it
probably shouldn't hurt putting a "probably" somewhere.)
> ==> the only shape that could profit from a displacement mapping feature
> is the mesh but apart from render time subdivision with displacement
> this is already possible to implement in SDL (or external programs).
"Is possible" and "is efficient" are two completely different things.
The idea in on-the-fly subdivision and displacement of meshes is that
it does not consume outrageous amounts of memory because the subdivision
and displacement can be done only to the part being currently rendered.
This way you can subdivide a mesh so that each triangle is split into
100 parts without the memory consumption growing noticeably. However,
if you subdivided the entire mesh so that each triangle was divided
into 100 parts and then rendered this entire mesh, the memory consumption
would skyrocket.
On-the-fly subdivision and displacement can't be done by modelling: It has
to be done by the renderer itself.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
>>- it is not possible to add a displacement feature to any shape POV-Ray
>>renders analytically.
>
>
> Change "possible" to "efficient" and then you may be right. (And it
> probably shouldn't hurt putting a "probably" somewhere.)
Well - then you would have to be able to give me an example of a POV-Ray
shape where you can modify the analytical root solver to support
displacement mapping. As long as you don't i keep my statement that
this is not possible (and i am quite sure about this).
>>==> the only shape that could profit from a displacement mapping feature
>>is the mesh but apart from render time subdivision with displacement
>>this is already possible to implement in SDL (or external programs).
>
> [...]
> On-the-fly subdivision and displacement can't be done by modelling: It has
> to be done by the renderer itself.
>
Is what i write somehow impossible to understand? If not i have no idea
why you post such a reply.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
>
> - it does not make any sense to add a displacement mapping feature to
> any higher level shape in POV-Ray that is internally rendered as a mesh.
Yes. I agree. That's exactly what I'm trying to say. Displacement could
be applied on the internal (triangle) mesh represenation.
> - it is not possible to add a displacement feature to any shape POV-Ray
> renders analytically.
I know.
> ==> the only shape that could profit from a displacement mapping feature
> is the mesh but apart from render time subdivision with displacement
Bicubic patches would profit.
In future (if somone finds it worthwile to implement it) nurbs and all
kind of subdivision surfaces could profit too.
> this is already possible to implement in SDL (or external programs).
SDL is slow.
To sum it up:
In this thread it was claimed that POV-Ray supports NURBS and that
POV-Ray can do displacment-mapping. This is simply not true. You can't
seriously argue that those things are supported *IN* POV-Ray by using an
*EXTERNAL* application!
-Sascha
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sascha Ledinsky wrote:
>
>> ==> the only shape that could profit from a displacement mapping
>> feature is the mesh but apart from render time subdivision with
>> displacement
>
>
> Bicubic patches would profit.
> In future (if somone finds it worthwile to implement it) nurbs and all
> kind of subdivision surfaces could profit too.
I am loosing interest in arguing here: As long as i have anything to say
there will be no feature added to POV-Ray or MegaPOV that adds support
for displacement mapping specifically to bicubic patches. A generic
mesh displacement might be interesting but redundant to some extent.
> To sum it up:
> In this thread it was claimed that POV-Ray supports NURBS and that
> POV-Ray can do displacment-mapping. This is simply not true. You can't
> seriously argue that those things are supported *IN* POV-Ray by using an
> *EXTERNAL* application!
At the risk of repeating myself: POV-Ray supports NURBS and
displacement mapping as much as (and more than as far as isosurfaces are
concerned) most other *renderers* available that use the raytracing
algorithm.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> Well - then you would have to be able to give me an example of a POV-Ray
> shape where you can modify the analytical root solver to support
> displacement mapping. As long as you don't i keep my statement that
> this is not possible (and i am quite sure about this).
Can you give me an example of how to shear an object without having to
do anything to the root solver? Naturally you can, because POV-Ray supports
exactly that: Instead of modifying the analytical representation of the
object, we modify the rays tested against the object.
I'm in no way implying it's *easy* or *efficient* to perform displacement
mapping by tracing non-linear rays, I'm just saying it's theoretically
*possible*.
> Is what i write somehow impossible to understand? If not i have no idea
> why you post such a reply.
You said "this is already possible to implement in SDL".
No, it's not. You can't implement in SDL a dynamic displacement mapping
engine which subdivides triangles on the fly while rendering.
You can subdivide the entire mesh before rendering and then render it,
but that requires quite a lot of extra memory. My point was that the whole
idea of supporting subdivision in the renderer is that it can perform
memory optimizations which allow almost unlimited subdivision with
limited amount of memory.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> A generic
> mesh displacement might be interesting but redundant to some extent.
It's certainly not redundant. Not if it's optimized to only subdivide
what is being currently rendering.
As I said earlier, this kind of optimization allows enormous subdivisions
with only a tiny extra memory requirement.
In other words: Imagine a 100MB mesh being subdivided so that each
triangle is divided into 100 triangles, and the result can be rendered
without requiring much more than the 100MB of RAM.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
>>Is what i write somehow impossible to understand? If not i have no idea
>>why you post such a reply.
>
>
> You said "this is already possible to implement in SDL".
> No, it's not. You can't implement in SDL a dynamic displacement mapping
> engine which subdivides triangles on the fly while rendering.
I wrote:
> the only shape that could profit from a displacement mapping feature
> is the mesh but apart from render time subdivision with displacement
> this is already possible to implement in SDL (or external programs).
I would appreciate it if you'd either read and cite me correctly or
refrain from replying.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> > the only shape that could profit from a displacement mapping feature
> > is the mesh but apart from render time subdivision with displacement
> > this is already possible to implement in SDL (or external programs).
> I would appreciate it if you'd either read and cite me correctly or
> refrain from replying.
I quoted you exactly and I said, and still say, that you are wrong.
I repeat, once again: The whole idea of a displacement mapping
supported by the renderer (vs. the modeller) is that the renderer
can optimize the memory usage of the mesh which the displacement is
applied to.
This is certainly not possible with the current SDL.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
