 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/24/2025 3:32 PM, Bald Eagle wrote:
> "jr" <cre### [at] gmail com> wrote:
>
>> "there you are" ;-). (attached, 42 vectors, 80 faces)
>
> Rock, paper, scissors.
>
> Bezier Parallelpiped crushes them all.
>
> - BE
Are you transforming the mesh as a whole or pulling the vertices out and
transforming them?
Josh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh English <Jos### [at] joshuarenglishcom> wrote:
> On 7/24/2025 3:32 PM, Bald Eagle wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> >
> >> "there you are" ;-). (attached, 42 vectors, 80 faces)
> >
> > Rock, paper, scissors.
> >
> > Bezier Parallelpiped crushes them all.
> >
> > - BE
>
> Are you transforming the mesh as a whole or pulling the vertices out and
> transforming them?
>
> Josh
Unfortunately, there's not a way (that I know of) to access the vertices in a
native mesh.
So I cut/pasted the vertices into an array, and put a loop into the mesh2 to
cycle through the array.
To be able to easily reuse the mesh2 definition, I set a flag to either use the
original vertices, or run a macro to apply the Bezier distortion.
#macro MakeMesh (Distorted)
mesh2 {
vertex_vectors {
42,
#for (V, 0, 41)
#if (Distorted)
DistortedVertex (MeshVertices [V]),
#else
MeshVertices [V],
#end
#end
}
.. . . etc.
I know it would be great if we could just easily include any mesh, or run it
through a macro, but at present, I don't think that there's any way to do that.
I am pretty happy that it just required some "minor" modification to the formula
generating code, and this wasn't a major multiple-month project.
Anyway, it shows proof of concept. :)
- BE
Attached please find all the gnarly, hastily modified code.
Post a reply to this message
Attachments:
Download 'bezier_3d_for_mesh.pov.txt' (19 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Unfortunately, there's not a way (that I know of) to access the vertices in a
> native mesh.
>
> So I cut/pasted the vertices into an array, and put a loop into the mesh2 to
> cycle through the array.
Perhaps a script could be written to convert mesh and mesh2 objects to arrays,
and then we can have a macro to define the mesh from those arrays.
> I know it would be great if we could just easily include any mesh, or run it
> through a macro, but at present, I don't think that there's any way to do that.
This hearkens back to the many discussions we've had about 4.0 and the
restructuring of the primitives and language structure.
I've seen some interesting discussions about taking something like a road or
brick wall, and using this approach to have the mesh follow the "spline".
Some pre-set deformations would be a nice thing to have, and one could simply
have a macro argument to control the degree of deformation.
Hourglass
Cylinder
Sphere
Twist
One face curving/collapsing to a point (like the following)
https://news.povray.org/povray.binaries.images/thread/%3Cweb.5e97c744fd34edcfb0b41570%40news.povray.org%3E/?ttop=444993
&toff=550
Two faces collapsing to points (like a lemon {} )
Two faces collapsing to points at different rates (like an ovus {} )
Bending into a square-cross-section U
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/25/2025 9:16 AM, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
>
> I've seen some interesting discussions about taking something like a road or
> brick wall, and using this approach to have the mesh follow the "spline".
>
My modeling system does this sort of thing. It can generate the spline,
do some copying and interpolation, and then build the wall. But it does
this entirely with arrays. I would like to be able to convert some of
these constructions into mesh2 objects, which will just take time, but I
can only do this kind of transformation on the array.
Josh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/25/2025 9:16 AM, Bald Eagle wrote:
> Perhaps a script could be written to convert mesh and mesh2 objects to arrays,
> and then we can have a macro to define the mesh from those arrays.
We would need to be able to serialize the mesh objects, though. I don't
know if 4.0 has any plans for that sort of thing. It would be nice to be
able to export them after a complicated modeling job.
Then again, I have Python at hand and I suspect most of us know other
coding languages that could do the same job. I'm trying to be an SDL
purist, probably to my detriment.
Josh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh English <Jos### [at] joshuarenglishcom> wrote:
> On 7/25/2025 9:16 AM, Bald Eagle wrote:
> > Perhaps a script could be written to convert mesh and mesh2 objects to arrays,
> > and then we can have a macro to define the mesh from those arrays.
>
> We would need to be able to serialize the mesh objects, though. I don't
> know if 4.0 has any plans for that sort of thing. It would be nice to be
> able to export them after a complicated modeling job.
>
> Then again, I have Python at hand and I suspect most of us know other
> coding languages that could do the same job. I'm trying to be an SDL
> purist, probably to my detriment.
>
> Josh
Well, we have #read and #write.
I've written tens of thousands of bicubic patch objects to files that way.
So it shouldn't be that big of a problem to write a distorted mesh to a new
file.
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
I liked the "boulder" on the right, pretty amazing.
> Josh English <Jos### [at] joshuarenglishcom> wrote:
> > On 7/25/2025 9:16 AM, Bald Eagle wrote:
> > > Perhaps a script could be written to convert mesh and mesh2 objects to arrays,
> > > and then we can have a macro to define the mesh from those arrays.
> >
> > We would need to be able to serialize the mesh objects, though. I don't
> > know if 4.0 has any plans for that sort of thing. It would be nice to be
> > able to export them after a complicated modeling job.
> >
> > Then again, I have Python at hand and I suspect most of us know other
> > coding languages that could do the same job. I'm trying to be an SDL
> > purist, probably to my detriment.
> >
> > Josh
>
> Well, we have #read and #write.
a "crutch" at best. unfortunately.
> I've written tens of thousands of bicubic patch objects to files that way.
and that knowledge, the experience, ought to be worth a "good wiki page". and
the same really for this thread, the deformations. I think that with a second
example perhaps and "fleshing out" your notes, this topic too would make a
useful/valuable reference in the wiki.
> So it shouldn't be that big of a problem to write a distorted mesh to a new
> file.
there's also the "upholstered crutch" :-), the 'Filed()' macro.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh,
for mesh and bicubic patches deformations of pre-made models is hard. One can
use scripts to extract .obj files in to mesh.
When one creates mesh and patches, things are easier. You can "just" remodel the
object with different parameters. Think extruding, lofting, sor or even
parametrics. Very old code below for patch modelling and clock guided
deformation.
The use of deformation grids (cubes) in 3d works. Sorry, my experiments for that
are lost. It is basically not so different from "boning", you have to virtually
"attach" vertices to the cubes in a grid. In similar vain you can use a single
spline to deform a mesh. But, it all has to be done to arrays. That's why I
build arrays first and the mesh from that in the meshmaker macros. When you
adapt the array building system you can add springiness, like in cloth
generation systems to get gel like objects that deform.
ingo
---%<------%<------%<---
// Ingo Janssen
// 1999-04-22
// bicubic patch generation
#version 3.1;
global_settings{assumed_gamma 1.0}
light_source{<100,50,-500> rgb 1}
camera{
location <0,0,-20.0>
look_at <0,0, 0.0>
}
#macro GetRadius1(R)
#local Range=R*0.1;
#local Variation=Range+(((-Range)-Range)*rand(S));
#declare Rr=R+Variation;
#end
#macro BuildArray(H,R,NrBPH,NrBPC)
// H= height; R= radius
// NrBPH= number of patches in height
// NrBPC= number of patches in circumference
#local PH=((NrBPH*4)-NrBPH)+1;
#local PC=((NrBPC*4)-NrBPC)+1;
#local Ystep=H/PH;
// need one extra element in the array for C1 continuity.
#local BP_arr=array[PH+1][PC+1]
#local Ypos=0;
#local I=0;
#local J=0;
#while (I<PH+1)
#while (J<PC-1)
#local Phi=(J*(360/PC));//+(I*((-180+clock*360)/PH));
GetRadius1(R)
#declare BP_arr[I][J]=vrotate(<Rr,Ypos,0>,<0,Phi,0>);
#local J=J+1;
#end //while
// closed shape so last point is first point.
#local BP_arr[I][J]= BP_arr[I][0];
// the last-plus-one point must be the same as the second point, too.
#local BP_arr[I][J+1]= BP_arr[I][1];
#local J=0;
#local Ypos=Ypos+Ystep;
#local I=I+1;
#end //while
#declare OutArray= BP_arr
#end //macro
#macro BuildPatch(InArray)
// the arrays were made an element larger, so here we must compensate.
#local PH= dimension_size (InArray,1)-1;
#local PC= dimension_size (InArray,2)-1;
#local I= 0;
#local J= 0;
#while (I<PH-1)
#while (J<PC-1)
bicubic_patch {
type 1
u_steps 4
v_steps 4,
InArray[I][J],
InArray[I][J+1],
// notice that the third point in each row is constrained such
// that it, the last point in the row, and the second point
// in the equivalent row in the next patch are in a straight line.(Ron Parker)
2*InArray[I][J+3]-InArray[I][J+4],
InArray[I][J+3],
InArray[I+1][J],
InArray[I+1][J+1],
2*InArray[I+1][J+3]-InArray[I+1][J+4],
InArray[I+1][J+3],
// notice, too, that each point in the entire third row is
// constrained in this way with respect to the last row and
// to the second row of the next patch. Note the lack of any
// +2 terms in the whole patch definition. We calculated them
// above, but we never use them because we no longer have as
// much freedom as we did before we wanted smoothness.(Ron Parker)
2*InArray[I+3][J]-InArray[I+4][J],
2*InArray[I+3][J+1]-InArray[I+4][J+1],
2*(2*InArray[I+3][J+3]-InArray[I+4][J+3])-(2*InArray[I+3][J+4]-InArray[I+4][J+4]),
2*InArray[I+3][J+3]-InArray[I+4][J+3],
InArray[I+3][J],
InArray[I+3][J+1],
2*InArray[I+3][J+3]-InArray[I+3][J+4],
InArray[I+3][J+3]
pigment {rgb 1}
}
#local J=J+3;
#end //while
#local J=0;
#local I=I+3;
#end //while
#end //macro
#macro ScaleArray(InArray)
#local PH= dimension_size (InArray,1);
#local PC= dimension_size (InArray,2);
#local I= 0;
#local J= 0;
#local Phi= 0;
#while (I<PH)
#while (J<PC)
#local Scale=sin(Phi)+0.5;
#local InArray[I][J]=InArray[I][J]*<Scale,1,Scale>;
#local J= J+1;
#end //while
#local J= 0;
#local Phi=Phi+(pi/(PH-2));
#local I= I+1;
#end //while
#declare OutArray= InArray
#end //macro
#declare S=seed(7);
BuildArray(15,5,25,15)
ScaleArray(OutArray)
union{
BuildPatch(OutArray)
rotate <0,0,90>
translate <7.5,0,0>
}
---%<------%<------%<---
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/26/2025 10:46 PM, ingo wrote:
> Josh,
>
> for mesh and bicubic patches deformations of pre-made models is hard. One can
> use scripts to extract .obj files in to mesh.
>
> When one creates mesh and patches, things are easier. You can "just" remodel the
> object with different parameters. Think extruding, lofting, sor or even
> parametrics. Very old code below for patch modelling and clock guided
> deformation.
>
> The use of deformation grids (cubes) in 3d works. Sorry, my experiments for that
> are lost. It is basically not so different from "boning", you have to virtually
> "attach" vertices to the cubes in a grid. In similar vain you can use a single
> spline to deform a mesh. But, it all has to be done to arrays. That's why I
> build arrays first and the mesh from that in the meshmaker macros. When you
> adapt the array building system you can add springiness, like in cloth
> generation systems to get gel like objects that deform.
My modeling system does this with a Modeling array and it then creates
the array of Control points needed to create the array of bicubic
patches I want.
I found Nathan Reed's page, quoting Inigo Quilez'
https://iquilezles.org/articles/ibilinear/, on the same bilinear
interpolation I've been doing on my modeling grids. What I hadn't been
doing was all the algebra that allows for hopefully a faster calculation.
My bicubic modeling system can handle sheets and cylinders and box-like
shapes, but so far I don't have an easy way to combine models into one
modeling array that would allow for sharp corners. I have a few ideas
brewing, but only sketches of how I could do it. I suspect for each
element of a building I want to have I'll need to create a macro to
generate the section, and then deform the control grid as needed. I'm
still noodling on it.
Josh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh English <Jos### [at] joshuarenglishcom> wrote:
> . . . but so far I don't have an easy way to combine models into one
> modeling array that would allow for sharp corners.
https://news.povray.org/povray.binaries.images/thread/%3Cweb.5da27a2a65c96eb4eec112d0%40news.povray.org%3E/?ttop=445868
&toff=650&mtop=428668
Like the leftmost part?
https://news.povray.org/povray.binaries.images/attachment/%3Cweb.5da912bb21826f334eec112d0%40news.povray.org%3E/serpent
inebeltprism.png?ttop=445868&toff=650
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
