So, I was pondering the extension of some patterns, and it occurred to me that
having a 3D primitive-based version of:

https://wiki.povray.org/content/Reference:Warp#Repeat_Warp

would be an excellent feature to be made available - especially for new users or
the non-mathematically inclined.

At present, I can define a set of functions to be evaluated as a pigment {}
pattern, and can use the repeat warp to infinitely tile a plane (or, I suppose,
all of 3D space)

However what I cannot do (*) is define a set of objects like spheres, and have
them infinitely repeated using the repeat warp.

* Now, what I can envision is somehow using the object {} pattern to laboriously
achieve this with some well thought out nesting of the inside and outside
textures (I do not have the ability to test this at the present moment) -
however that seems to be very labor intensive, takes a bit of skill and/or macro
writing, and may not work as I imagine it could.

The idea there being that the objects could be assigned the inside texture,
while the outside would be a transparent rgbt 1.   Then a "thick box" - the
intersection of 2 planes could be assigned that object {} texture with a repeat
warp applied.

I think it would be vastly easier on the user, and probably much faster if
implemented internally, so that one could simply define a typical CSG object,
textured in the usual manner, and then use the min & max_extents to define the
repeat vectors (perhaps as the default).

Thoughts, criticisms, comments on the feasibility, and SDL / source
implementations welcome.  ;)

- BE

Post a reply to this message

I'm a bit confused as to what the final result should be, or what it should look
like when applied(?) to your two infinite planes. (I'm actually not sure what
those planes are for.)

For endlessly repeating a textured 3D object (like a sphere) *as* 3D objects, a
simple or nested #for-loop construct would be the easy solution, with each
sphere offset of course; no 'repeat warp' necessary. But I sense that you're
seeking something different or more complex...possibly involving an 'object
pattern' use?

More details please!

----------
I haven't posted to the newsgroups in a long while-- real life and work have
taken up my time-- but I'm still reading the posts here. My so-called
'high-speed' internet connection has been problematic too; sometimes it works
fine, but most of the time it's as slow as molasses, and I can't even load a web
page. No idea why.

I've also been working for months on various schemes to tesselate a typical
pre-made POV-ray object (to eventually turn it directly into an .stl file for
3-D printing). I've solved *some* of the problems, but the overall solution
still eludes me :-\  I haven't given up though!

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> I'm a bit confused as to what the final result should be, or what it should look
> like when applied(?) to your two infinite planes.

Any of our current pigment patterns are procedurally generated, meaning that
they return some value given only the <x, y, z> coordinates as input.
What that essentially means is that there is actually no "pattern" that globally
 exists as a monolithic pre-made thing, but simply a method for determining what
 is at any given point in space when actually evaluated by the raytracer.

> (I'm actually not sure what
> those planes are for.)

The planes would be the limits of the 3D space evaluated for applying the warp
repeat - kinda like an infinite bounding box of a certain thickness.
A "thick plane".

> For endlessly repeating a textured 3D object (like a sphere) *as* 3D objects, a
> simple or nested #for-loop construct would be the easy solution, with each
> sphere offset of course; no 'repeat warp' necessary.

No sir.  I cannot do #for (i, 0, inf)
And I'd have to know _where_ to place all of those 3D objects ahead of time.

What I'm talking about is truly infinite.
Just like our current procedural patterns.


> But I sense that you're
> seeking something different or more complex...possibly involving an 'object
> pattern' use?

Yes, like I mentioned before, it would be "as though" one used the object
pattern, but this would be implemented rather differently to make it simpler.

> More details please!

So, picture I have the unit cube.  I can place 8 spheres in the unit cube "in
the corners" each tangent to 3 sides and 3 other spheres.
I our usual scenes, I could give these spheres a rich pallete of colors,
patterns, normals, finishes, etc.
What I'm simply envisioning is having that unit cell get substituted into ANY
unit cell encompassed by the repeat warp parameters.
So if I repeated it in the x and z directions, I would get a "plane" of that
unit cell containing those 8 spheres anywhere I looked - wherever the camera was
placed, and however far away from the origin I chose.
I could animate the camera position and keep going and going and going, and
there would truly be an infinite number of spheres. (Naturally constrained to
the abilities of the computer to store and represent the <x, y, z> coordinates)

It's that same effect as making an isosurface using <mod (x, 1), y, mod(z,1)>,
but it would be handled much more efficiently vis source, _and it would carry
all of the material properties with it_.
So it would be thousands of times faster and probably tens of thousands of times
less tedious to implement.



> I've also been working for months on various schemes to tesselate a typical
> pre-made POV-ray object (to eventually turn it directly into an .stl file for
> 3-D printing). I've solved *some* of the problems, but the overall solution
> still eludes me :-\  I haven't given up though!

"tesselate" --- More details please!  ;)

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> At present, I can define a set of functions to be evaluated as a pigment {}
> pattern, and can use the repeat warp to infinitely tile a plane (or, I suppose,
> all of 3D space)
>
> However what I cannot do (*) is define a set of objects like spheres, and have
> them infinitely repeated using the repeat warp.
>
>* Now, what I can envision is somehow using the object {} pattern to laboriously
> achieve this with some well thought out nesting of the inside and outside
> textures (I do not have the ability to test this at the present moment) -
> however that seems to be very labor intensive, takes a bit of skill and/or macro
> writing, and may not work as I imagine it could.
>


There no infinitely repeating objects! There is a limit. Even with functions
there a point where pov variables can't reach. I was playing with the random
seed the other day to see just how big of number in would take. After 10 digits
the seed acted like only the first 10 where used.

 If I understand you right, you're trying to fake it with a pattern that holds
all the different textures of a union of objects, that can use a warp repeat
type function to fix things up.
 The trouble with pigments or textures is that they need an object to be on. And
any object used only shows what hits it. If you want to see a union of objects
as a 3d pattern you need something 3d that shows only what is part of the
pattern and let light pass through otherwise.
 My first thought was df3 files with media . It might work for pigments only but
trying to use the full texture function might cause problems. And df3 files have
to be large to keep from being  grainy and they are limited.
 Any way I look at it, even if we got something to work it would only be
effective for a relative short distance before it blurs out like most textures
do.

Have Fun

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:

> There no infinitely repeating objects! There is a limit. Even with functions
> there a point where pov variables can't reach. I was playing with the random
> seed the other day to see just how big of number in would take. After 10 digits
> the seed acted like only the first 10 where used.

Like I said - there is only the limit of the ability of the computer to store
and represent the values.
But within those limits, we can generate "infinite numbers" of objects.


>  If I understand you right, you're trying to fake it with a pattern that holds
> all the different textures of a union of objects, that can use a warp repeat
> type function to fix things up.
>  The trouble with pigments or textures is that they need an object to be on. And
> any object used only shows what hits it. If you want to see a union of objects
> as a 3d pattern you need something 3d that shows only what is part of the
> pattern and let light pass through otherwise.

I'm not trying to fake anything.
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.

Post a reply to this message

Attachments:
Download 'infinite spheres.png' (367 KB)

Preview of image 'infinite spheres.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:

> > I've also been working for months on various schemes to tesselate a typical
> > pre-made POV-ray object (to eventually turn it directly into an .stl file for
> > 3-D printing). I've solved *some* of the problems, but the overall solution
> > still eludes me :-\  I haven't given up though!
>
> "tesselate" --- More details please!  ;)
>

As in, taking any pre-made object and turning it into a triangle mesh surface--
even objects with holes, voids, undercuts, etc. So far, I have solved only 'step
A'-- finding regularly-spaced points on all the surfaces, without picking
redundant points. Even that's not quite perfect, though. The *bigger* problem is
how to logically connect those points to make triangles... which is the 'holy
grail' of the entire scheme, of course!

As alternatives:
I've looked at the old 'marching cubes' algorithm, but that does not seem to be
appropriate, as it deals with isosurfaces and look-up tables. I don't know
though.

There is also a 'pivoting ball' algorithm that looks more promising, although I
don't yet know how I would implement it in SDL.

Anyway, I didn't mean to hi-jack your post...

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> There is also a 'pivoting ball' algorithm that looks more promising,
> although I don't yet know how I would implement it in SDL.
>

Here's a PDF file of the idea, by the original authors...

https://mesh.brown.edu/taubin/pdfs/bernardini-etal-tvcg99.pdf

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> As in, taking any pre-made object and turning it into a triangle mesh surface--
> even objects with holes, voids, undercuts, etc. So far, I have solved only 'step
> A'-- finding regularly-spaced points on all the surfaces, without picking
> redundant points. Even that's not quite perfect, though. The *bigger* problem is
> how to logically connect those points to make triangles... which is the 'holy
> grail' of the entire scheme, of course!

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.


regards, jr.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> As in, taking any pre-made object and turning it into a triangle mesh surface--
> even objects with holes, voids, undercuts, etc. So far, I have solved only 'step
> A'-- finding regularly-spaced points on all the surfaces, without picking
> redundant points. Even that's not quite perfect, though.

Using something like a progressive trace () to generate a crossing number (used
for insidedness tests for polygons, but storing all of the crossing points would
allow this.

https://news.povray.org/povray.pov4.discussion.general/message/%3Cweb.662158a818d5960295196c9d25979125%40news.povray.or
g%3E/#%3Cweb.662158a818d5960295196c9d25979125%40news.povray.org%3E

> The *bigger* problem is
> how to logically connect those points to make triangles... which is the 'holy
> grail' of the entire scheme, of course!

Well, that's why it's easy to convert parametric shapes into meshes, since you
can cycle through the values and calculate where the next point is.

Looking at primitive CSG's or isosurfaces, you're sort of working backwards.
You have a value of sorts, but you don't have access to the underlying mechanism
of how it was generated. (This is also what bothers me about POV-Ray's
parametric {} object - why the hell is it so slow? )

Anyway, none of that really has to do with the repeat warp mechanism for
primitives. . .

- BW

Post a reply to this message

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)

-- 
Thomas

Post a reply to this message

Attachments:
Download 'makemesh.inc.txt' (6 KB)