 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 10-8-2024 om 09:32 schreef Thomas de Groot:
> Op 9-8-2024 om 19:33 schreef jr:
>> ingo wrote/published a "meshmaker" macro[*], I guess you could explore
>> that code
>> for ideas, there's also a "nagging feeling" of having forgotten
>> another mesh2
>> generating macro published in the NGs.
>>
>> [*] which I haven't to hand, sorry.
>>
>>
> I add it here.
>
> I have used it, though I don't remember when exactly, I should have a
> pov-scene somewhere.... (looking for it)
>
My memory is not what it has been :(
meshmaker.inc can be found in the official POV-Ray/include folder.....
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Thomas de Groot <tho### [at] degroot org> wrote:
> ...
> My memory is not what it has been :(
know the feeling..
> meshmaker.inc can be found in the official POV-Ray/include folder.....
perhaps that is what I was thinking of, unsure now :-).
@Kenneth
fwiw, I had a look in "the collection" too, and got 2 and-a-half :-) "hits":
/meshrelief
The meshrelief include file comprises a set of macros that create meshes of
simple shapes, and displace the surfaces according to a predefined pigment.
These macros are intended for creating realistic, but relatively low-detail,
building blocks that can be copied many times to build structures, and render
many times faster than the equivalent isosurfaces.
/meshlathe
Lathes are often useful to easily create objects like wineglasses, pots, etc.
However, often they can be rather slow to render. This include file creates a
triangle mesh from a spline by rotating it around the y axis, similarly to how
the lathe object works. Several options and parameters to define the amount of
triangles and debugging features are supported, as demonstrated in the example
pov file and the image (rendered from it).
/scroll (Scroll_array2mesh2.inc)
Include file for the Scroll_Mesh2FromArray macro takes an array of Positions and
generates a mesh2 object.
if you're interested, I can post the zip(s).
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2024-08-10 03:56 (-4), Thomas de Groot wrote:
>
> meshmaker.inc can be found in the official POV-Ray/include folder.....
If you are using POV-Ray 3.7, please note that there is a bug in
meshmaker.inc 3.7. It is fixed in POV-Ray 3.8, and should work without
modification if you copy it to your 3.7 include folder.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 10-8-2024 om 18:10 schreef Cousin Ricky:
> On 2024-08-10 03:56 (-4), Thomas de Groot wrote:
>>
>> meshmaker.inc can be found in the official POV-Ray/include folder.....
>
> If you are using POV-Ray 3.7, please note that there is a bug in
> meshmaker.inc 3.7. It is fixed in POV-Ray 3.8, and should work without
> modification if you copy it to your 3.7 include folder.
>
Ah! Good to remind us of this, and thanks!
I use 3.8 most of the time, but I shall do as you say.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> When we have meshes, with multiple instantiations, we merely apply a
> transformation matrix to the reference mesh in order to do the calculations to
> find the new position of the copy.
>
> If we simply apply the same methods to ACTUAL TEXTURED OBJECTS, then we
> ought to be able to accomplish exactly the same thing. When I texture an
> object, and THEN translate it, the texture "follows" it. So i ought to be
> able to define a unit cell with a vector, and then simply use mod () to
> repeat that unit EVERYWHERE.
>
> The attached is an isosurface of a 100 x 100 grid using mod () which rendered
> in 7 seconds. We KNOW primitives render much faster than isosurfaces, and
> so would be a feasible way to accomplish the same thing only using all of
> the native optimizing of CSG objects.
(Sorry for the long delay in responding. I finally got a little bit of free
time-- but then my internet connection went down completely for 3 days; no clue
as to why. There's a bad technical glitch somewhere...) Anyway...
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. 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?
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.
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.)
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 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.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And to follow up a little further on that,
See:
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d3c5fe27be432e04eec112d0%40news.povray.org%3E/?ttop=443897
&toff=600
All of those rocks are a single isosurface.
I can pattern them uniquely, as I have, but having a ray intersection that
triggers - not the usual texture evaluation - but a blindingly faster stored
value from a "lookup table" derived from a single evaluation of the basis unit
cell - I think would make a scene with a complex texture render MUCH faster.
Mod () is just a "portal" to the cell defined by the magnitude of the divisor.
A grid of TV screens all showing the same image. Cahnge the image, change ALL
the cells.
You don't have a lot of images where you have to change all of them
individually.
https://en.wikipedia.org/wiki/Modulo
Just think about making your faked pattern with real objects.
Let's say its a Lego.
You place all the Legos next to each other - but you already know what the next
spot is going to look like even before it gets filled in, because they're all
identical to the first Lego. The Nth Lego is just an identical copy of the
first one.
And the unit cell is defined by the dimensions of the Lego - that's your unit.
But you can still make them all "look different" - even though the underlying
pigment is the same - by lining them up so they go through a tunnel and out
again, and only lighting them from one side.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
