|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi POV'ers!
Here's an example of my macros so far. The left object is POV primitives.
The right object is a traced and blurred heightfield, done with my macros.
The reason why it looks a bit stretched in the Y direction is a bug, but I
planned it as an effect anyway (that you can turn off).
I think the quality is fair, given the grid is only 64*64. The macros are
very easy to use. They don't require the same math knowledge as isosurfaces.
I know this will please some. :o) But they're limited to making
heightfields. There will usually be some artifacts compared to your original
object, but it's not necessarely going to look bad.
I haven't yet programmed cylindrical heightfields, because I'm confused over
function {}.. I think the best is to have the user specify a function for
this, but Pov complains when I try to get it into my vertex position loops.
Parsing is a bit slow while the mesh is being build.. The attached image
needed 40 seconds to parse on my 1 ghz computer, but the resulting mesh2 can
be saved & loaded in all your future scenes, and then it will be very fast.
I'll release the macros soon. I don't know how useful you think this is, but
in some cases I think, I can use it myself.. I also tried to code in a clean
way so other people can add to it..
Regards,
Hugo
Post a reply to this message
Attachments:
Download 'HFmacros.JPG' (39 KB)
Preview of image 'HFmacros.JPG'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
That looks AWESOME. I can see a lot of utility with this macro for making
thinks like stamped text, worn stone tablets, knobby bronze objects, etc. I
have tried creating this effect in the past with a low resolution
heightfield, but without your square dividing algorithm, the results were
quite poor.
If you can wait for just one more day, I have been doing some speed
experiments and can speed up the normalizing algorithm a LOT. I have removed
the extra steps from the algorithm, "functionalized" all of my formulas, and
combined some processes. And in defense of all of my rewrites. I can at
least say that my first version worked as intended. <g>
-Shay
Hugo <hua### [at] post3teledk> wrote in message news:3c877297@news.povray.org...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Shay,
I'm glad you like it! I must admit the normalizing code is still the one
from your first version. I have been busy with implementing vertex-blurring
(not connected with normal smoothing). And I use a fixed 4 times
"oversampling" during trace of the original object, that improves shape. All
in all those things add to the parse time, but none of them are extremely
slow by themselves.
I'd very much like to see what you have in mind. I have no idea how it works
as a function {} But before you spend a lot of time writing new code, maybe
I should show how I implemented the first one. It was the section about
storing normals in an array, that I really needed, the rest was already
working in my code. So I removed my normal junk-code and used this:
// My macro to calculate normal of a triangle plane
#macro CalcNorm(Face_Cnt)
#local V1=Vertices[Faces[Face_Cnt].x];
#local V2=Vertices[Faces[Face_Cnt].y];
#local V3=Vertices[Faces[Face_Cnt].z];
vcross(V2-V1,V3-V1);
#end
// Find normals of 2 faces in a sqaure
#local Normal_1=CalcNorm(Face_Cnt);
#local Normal_2=CalcNorm(Face_Cnt+1);
// Your code:
#declare Mesh_Normals[Column_Counter][Row_Counter] =
Mesh_Normals[Column_Counter][Row_Counter]
+Normal_1 +Normal_2;
#declare Mesh_Normals[Column_Counter+1][Row_Counter] =
Mesh_Normals[Column_Counter][Row_Counter+1]
+Normal_1;
#declare Mesh_Normals[Column_Counter+1][Row_Counter+1] =
Mesh_Normals[Column_Counter+1][Row_Counter+1]
+Normal_1 +Normal_2;
#declare Mesh_Normals[Column_Counter][Row_Counter+1] =
Mesh_Normals[Column_Counter][Row_Counter+1]
+Normal_2;
... and the same code again for the other case-status but with swapped
normal_1 / normal_2 addition.. Will your extended code be able to fit in
here somewhere? :o)
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hugo <hua### [at] post3teledk> wrote in message news:3c87948e@news.povray.org...
> // My macro to calculate normal of a triangle plane
> #macro CalcNorm(Face_Cnt)
> #local V1=Vertices[Faces[Face_Cnt].x];
> #local V2=Vertices[Faces[Face_Cnt].y];
> #local V3=Vertices[Faces[Face_Cnt].z];
> vcross(V2-V1,V3-V1);
> #end
>
> Will your extended code be able to fit in
> here somewhere? :o)
Check this out. My final code is already implemented. This is what I have
been testing. Tor said in another thread that normalizing sums of the
non-normalized vcross of each triangle would give the correct weighted
normal, and he was correct. The only necessary change was from
VPerp_To_Plane to vcross. This actually removes a step, not adds one. I have
tested this several times and have gotten identical results to finding the
normal and area in two seperate steps!
I am pretty sure that vcross(V2-V1,V1-V3) gives a more accurate result than
vcross(V2-V1,V3-V1). Just going on what I have heard on that one. Haven't
tested it myself.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <sah### [at] simcopartscom> wrote in message
news:3c879d9f$1@news.povray.org...
>. The only necessary change was from
> VPerp_To_Plane to vcross. This actually removes a step, not adds one.
I think my biggest mistake is not fillowing up when I made this assumption
on March 5. I posted that I thought this might be the case, but then I
forgot all about it. Live and learn, I guess.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Tor said in another thread that normalizing sums of
> the non-normalized vcross of each triangle would
> give the correct weighted normal, and he was correct
Does this mean, I'm now using weighted normals and not just averaged ones?
I actually didn't know. It's some time ago I decided to skip vnormalize
until the very end as this seemed logical. But I don't always know what I'm
doing.
> I am pretty sure that vcross(V2-V1,V1-V3) gives
> a more accurate result
I'll try, thanks for the tip!
Regards
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay wrote:
>
>...
> I am pretty sure that vcross(V2-V1,V1-V3) gives a more accurate result than
> vcross(V2-V1,V3-V1). Just going on what I have heard on that one. Haven't
> tested it myself.
vcross(v2 - v1, v3 - v1) = - vcross(v2 - v1, v1 - v3)
And further:
vcross(vA, vA) = <0, 0, 0>
vcross(s*vA, vB) = vcross(vA, s*vB) = s*vcross(vA, vB)
vcross(vA, vB/t) = vcross(vA/t, vB) = vcross(vA, vB)/t
vcross(s*vA, vB/t) = vcross(vA, vB)*s/t
vcross( vA, vB) = - vcross(vB, vA)
vcross(-vA, vB) = vcross(vA, -vB) = - vcross(vA, vB)
vcross(vA + vB, vC) = vcross(vA, vC) + vcross(vB, vC)
vcross(vA, vB - vC) = vcross(vA, vB) - vcross(vA, vC)
vcross(vA - vB, vC - vD)
= vcross(vA, vC - vD) - vcross(vB, vC - vD)
= vcross(vA, vC) - vcross(vA, vD) - vcross(vB, vC) + vcross(vB, vD)
vlength(vcross(vA, vB))
= vlength(vA)*vlength(vB)*sin(AngleBetween(vA, vB))
sin(AngleBetween(vA, vB))
= vlength(vcross(vnormalize(vA), vnormalize(vB)))
vnormalize(vcross(vA, vB))
= vcross(vA, vB)/vlength(vA)/vlength(vB)/sin(AngleBetween(vA, vB))
vcross(vnormalize(vA), normalize(vB))
= vnormalize(vcross(vA, vB))*sin(AngleBetween(vA, vB))
vlength(vA)*sin(AngleBetween(vA, vB))
= vlength(vcross(vA, vnormalize(vB)))
... and so on ...
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You're obviously an expert, Tor!! :o) It's good we have people like you
here in the newsgroups. I appreciate all the math that has already been
coded into Pov and the great macros you people make. My contributions are
not really fancy in terms of demonstrating math.. I just tried to make a
tool that is easy to model with.. And for once, I feel I got further than
any prior attempts.. :o) That makes my day, as people say.. But I'm not
finished. :o)
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hugo wrote:
>
> You're obviously an expert, Tor!! :o)
Hehe, I think not.
I have just re-studied some of the math
stuff I learned back at the gymnasium
(high school ?).
Back then I did not understand the power
of the basic 3D math we were taught.
And we did not have POV-Ray and today's
powerful computers =(
>...
> It's good we have people like you
> here in the newsgroups. I appreciate all the math that has already been
> coded into Pov and the great macros you people make. My contributions are
> not really fancy in terms of demonstrating math.. I just tried to make a
> tool that is easy to model with.. And for once, I feel I got further than
> any prior attempts.. :o) That makes my day, as people say.. But I'm not
> finished. :o)
Thank you for sharing your mesh ideas Hugo.
Your's and Shay's sample scenes increased
my interest for parametric and mesh surfaces.
If you guys hadn't started your mesh
discussions, I would probably not have
thought of "meshyfying" my parametric
surfaces.
I must say that I'm looking forward to
seeing the results of your work.
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|