POV-Ray : Newsgroups : povray.pov4.discussion.general : 3D warp repeat for primitives : Re: 3D warp repeat for primitives Server Time
31 Oct 2024 10:20:18 EDT (-0400)
  Re: 3D warp repeat for primitives  
From: Bald Eagle
Date: 16 Aug 2024 21:20:00
Message: <web.66bffa2ec952a0691f9dae3025979125@news.povray.org>
> SO...From your isosurface/spheres render-- as your analogue-- I have a much
> clearer idea of what you're after: a (quasi-)infinite built-in 'pattern' of 3-D
> objects via a warp/repeat or some such, using any(?) kind of pre-made object as
> the 'unit', not just a sphere.

YES.

> Then the underlying pattern mechanism can place
> the objects within a pre-defined(?) set of planes, appearing to go to infinity
> in at least 2 if not all 3 axes (but constrained by the planes.) And
> accomplished very quickly, because the basic pattern is built-in behind the
> scenes, rather than having to code the entire shebang in SDL. Correct so far?

Well - the objects are coded in SDL.
The repeating unit cell is defined by the "vector" or however the actual
implementation would be defined.   Maybe just an automatic bounding box of the
union.
(The set of planes is just sort of a way to bound the isosurface analogue - we
likely don't need it for the actual source implementation)
Then the way the pattern is repeated is handled by the warp specified by the
user.


> It's an intriguing idea...but I still wonder if *nearly* the same thing could be
> accomplished visually-- albeit in a much slower way-- by nested #for loops, to
> place the (*many!*) objects in such a grid-like arrangement, 'appearing' to go
> to infinity even though the loops have finite start and end locations.

Well yes - we can fake such things - but what if we're talking about an
isosurface or a parametric.  Or _anything_ that renders slowly.
The magic of mod () is that when you solve the equation for <x, y, z> once, you
have solved it for every mod (<x, y, z>, N) in all of 3D space.
Because everything is just a copy of that basis unit cell.
Obviously lighting and shadow and everything else needs to be calculated because
the absolute coordinates are different and there are differences in lighting and
proximity to other scene elements - but the geometry and texture is already
established at that point for every analogous point in every other unit cell.

> As has been mentioned, even POV-ray's typical built-in patterns-- when applied
> to a plane, for example-- lose their definition the farther the pattern is from
> the camera. So having the 3-D objects go all the way to 'infinity' (i.e.
> quasi-infinity) may not be necessary anyway; instead, only as far as what looks
> like infinity, before they lose their definition too. (I hope that makes sense.)

Yes, yes, we can fake many things - but that's not the point.

> And if the camera moves during an animation, it seems to me that the #for-loop
> construction could easily be adjusted to keep the many objects looking like they
> still go out to quasi-infinity (by changing the finite start and end locations
> in the loops.)

But that has to be babysat by the (new) user.
How would you like to have to explicitly define the extent of any pigment {}
statement that you used in a scene rather than just being able to rely on the
fact that that procedural pattern is inherent in the very 3D-space of the scene?

> But I agree that it would be nice to have such an 'infinite 3-D-object pattern'
> built-in, if only for the vast parse/render-speed increase.

It would be faster and require far less memory.

> BTW: If your code for your red-spheres-isosurface analogue scene is still
> intact, would you mind posting it here? I would like to see how and where you
> used your 'mod' code to get the repeating spheres in the isosurface. I haven't
> used such a trick before.

Of course.
Notice that that entire thing is a single isosurface.

You have Mike Williams' site that I converted to PDF - just search for "mod" and
it ought to be the first search result.

Also read his web page on holes to see an(other) excellent example of how
efficient and fast "baking" a feature into the equations is.


Notice that I have ONE shape - a sphere with a radius of 0.5, so that the
diameter is the width of a unit cell. Mod () takes care of the rest no matter
how large you set Ext to be, or where (in that narrow slice of space) you
position the contained_by box.
------------------------------------------------------------------------

#version 3.8;
global_settings {assumed_gamma 1.0 }

camera {
 location <0, 4, -40>
 right x*image_width/image_height
 up y
 look_at <0, 0, 0>
}

light_source {<0, 5, -50> rgb 1}

sky_sphere {pigment {rgb 1}}

#declare Ext = 100;
#declare Radius = 0.5;
#declare Sphere = function (X, Y, Z) {sqrt(X*X+Y*Y+Z*Z)-Radius}
isosurface {
   function {Sphere (mod(abs(x),1)-0.5, y, mod(abs(z),1)-0.5)}
   max_gradient 1

   accuracy     0.001
   contained_by {box {-<Ext, 0.6, Ext>, <Ext, 0.6, Ext>}}
     texture {pigment {rgb x} finish {specular 0.4}}
}


Post a reply to this message

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