|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18/08/2016 à 18:49, clipka a écrit :
> Am 18.08.2016 um 18:13 schrieb clipka:
>> As for the union of individual triangles, I'm still working on that one;
>> I must confess that so far I don't really have a clue where things go wrong.
>
> Yikes!
>
> I've found the culprit.
>
>
> You see, after parsing the triangle vertices, POV-Ray invokes a piece of
> code that precomputes certain values for the triangle that will be
> required in each and every intersection test.
>
> That code first computes the surface normal from the vertices, as well
> as the distance between the coordinate origin and the plane in which the
> triangle lies.
>
> The code then goes on to enforce a certain ordering of vertices that
> allows for certain shortcuts in intersection testing. You may note that
> this shouldn't be a problem for the interior/exterior texture test,
> since the surface normal has already been computed at this point.
>
>
> It /does/ become a problem, however, as soon as you invoke any
> transformation on the triangle -- because such an operation changes the
> position of the vertices, and therefore requires a re-computation of the
> precomputed stuff.
>
> And this time the precomputation will operate on potentially rearranged
> vertices.
>
>
> As I said: Yikes!
>
Nicely spotted, and it applies only to triangle outside a mesh.
Nevertheless, aside from passing the swapped status during computation of data, do we
really need to store that bit in each triangle ?
(moreover, in something not "unsigned int :1", which might actually extend the size of
the Triangle structure)
And did you check the SmoothTriangle::Compute_Triangle ?
Similar code with extra swapping of normal at vertices, yet the Normal_Vector is the
same old way as Triangle::Compute_Triangle.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.08.2016 um 22:30 schrieb Le_Forgeron:
> Nicely spotted, and it applies only to triangle outside a mesh.
Evidently, since meshes don't manipulate their data for transformations;
they just store a transformation matrix.
> Nevertheless, aside from passing the swapped status during computation of data, do
we really need to store that bit in each triangle ?
> (moreover, in something not "unsigned int :1", which might actually extend the size
of the Triangle structure)
I could have chosen from a host of approaches:
(A) Keep the original order of the points, and store the potentially
rearranged points as separate variables. This probably qualifies as the
most straightforward solution, and would be virtually(*) neutral to
rendering speed, but would require 24 extra bytes of data.
(*The only mechanism that could lead to a slight decrease in rendering
performance would be an increase in cache misses due to the larger
memory footprint.)
(B) Keep the original order of the points, and modify the intersection
test to cope with arbitrary ordering of the points. This undoubtedly
qualifies as one of the most memory-efficient solutions, but would also
undoubtedly be the heaviest on rendering performance. It would also
require some thought to be put into the intersection testing.
(C) Allow the order of points to be rearranged, but keep track of this
fact with a single flag, and fix the surface normal computation
accordingly. This is also a relatively straightforward to implement,
virtually neutral to rendering speed, and in theory costs only a single
bit of memory.
(D) Allow the order of points to be rearranged, identifying this fact
from /some/ properties of the underlying data wherever it is relevant.
This also undoubtedly qualifies as one of the most memory-efficient
solutions, and it can probably be implemented in a performance-neutral
manner (as far as rendering is concerned; parsing would be slowed down a
bit), but it would require some thought and care to be put into the
implementation, to make sure the properties we're basing the test on
actually hold true. It may also turn out to require either non-trivial
changes to the architecture of the Triangle's pre-computation mechanism,
hence resulting in a comparatively high implementation effort; or
changes spread across various methods, that would make the solution
non-trivial to understand, thereby degrading maintainability.
Weighing all the pros and cons, I decided that (C) was a reasonable
solution.
As for chosing a `bool:1`, I am a passionate advocate of storing data in
adequate data types, and booleans /are not integers/, period. I'm using
a `bool:1` as oppsoed to a regular `bool` in hopes that some modern
compilers make use of the freedom given by the C++ standard and cram it
into the same byte as the preceding `unsigned int:2` fields, but if they
don't -- well, too bad. I won't sacrifice clean programming for such a
tiny bit of memory.
As a matter of fact...
- On Linux systems, http://stackoverflow.com/a/308393 suggests that at
least GCC 4.2.4 will indeed pack `[unsigned] int` and `bool` bit fields
snugly together, so no memory lost there.
- On Windows systems, my own tests indicate that Visual Studio 2010 will
refuse to pack the two bit fields together. However, thanks to the
preceding `double` field the `unsigned int` bit field will be aligned to
an 8-byte boundary, and effectively occupy a multiple of 8 bytes in
memory; and since `int` is only 4 bytes on Windows machines, that still
leaves enough room afzer the `unsigned int` bit field to accomodate the
`bool:1` without any loss.
Also, if you were that worried about memory consumption, you should be
more bothered by the `unsigned int:2` where `unsigned char:2` would
suffice; while the difference is only 3 bytes on Windows or 32-bit Linux
machines, on 64-bit Linux machines it is a waste of 7 bytes. (BTW, it so
happens that Visual Studio 2010 apparently /will/ happily pack `unsigned
char` and `bool` bit fields together.)
> And did you check the SmoothTriangle::Compute_Triangle ?
> Similar code with extra swapping of normal at vertices, yet the Normal_Vector is the
same old way as Triangle::Compute_Triangle.
For `SmoothTriangle`, the direction of `Normal_Vector` is irrelevant,
since it is only used in the intersection computations, where a
distinction between front and back side is of no concern. The only
important thing is that the direction of `Normal_Vector` matches the
sign of `Distance`.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Swapping the 1's and Phi's in the TwentyHedron definition gives a nice
> regular icosahedron.
From : https://en.wikipedia.org/wiki/Regular_icosahedron
The vertices of an icosahedron with edge-length 2, centered at the origin, are
where ϕ = (1 + √5) / 2 is the golden ratio (also written τ).
Note that these vertices form five sets of three concentric, mutually orthogonal
golden rectangles, whose edges form Borromean rings.
But I tend to be able to misread things rather well. ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Hrrmpf... When it comes to error reports, I prefer precision. "not much"
> != "absolutely nothing".
Indeed.
I'm currently RE-taking inventory because the first time was inadequate and
questionable. :|
From one to another - "precision" is the clustering of results, not necessarily
the intended goal.
"Accuracy" is hitting your mark.
One can be WAY off target and still be precise if they consistenly hit in the
same place.
One is "accurate" if the target is approached closely.
Just an observation from a rifle instructor, and a scientist schooled in
statistics by a statistician. ;)
What hidden wonders POV-ray offers, eh?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> One thing is for sure: You've seriously screwed up on the icosahedron.
>
> Apparently you misinterpreted the positions of the individual points,
> probably thinking that Phi<1, but in fact Phi>1.
>
> Swapping the 1's and Phi's in the TwentyHedron definition gives a nice
> regular icosahedron.
Are you just pulling my leg now?
Because my definition of Phi is in the code, and when I comment out ALL of the
vnormalize() directives, I get ... an icosahedron.
And considering that the vertices are defined by ALL of the permutations of
+/-1, 0, and +/-Phi, I don't see how "swapping" those values in any given vertex
doesn't just give me ... another one of the points I already have.
When I added the y-rotated 90 and 180 instances, the lighting made it _look_
strange, like one triangle was rotated and skewed at a weird angle, but I added
a granite surface normal and moved the light source, and it's --- just an
icosahedron. Were you seeing the same optical illusion I did?
> You also got the front top cap's ordering of points wrong. Fixing that
> will give you a nicely textured mesh.
Correct. I've fixed that, and thank you.
I'm going to add a little bit to my code to visualize the vertex normals of the
smooth_triangles, because I'm having a devil of a time visualizing your
description of how that all works at the moment. Your explanation of the
situation is perfectly clear - the 3D result of that is just [for me] less so.
Please also notice that there are a few green pixels in/on the lower left MESH
icosahdron - the rotate y*180 degree instance. A small, but seemingly important
detail, if using mesh{} is supposed to eliminate that problem.
I haven't declared an inside_vector - could it be related in some way to that?
Also, if only _some_ of the vertices are normalized to the unit sphere radius,
some very nice stellated / fractal shapes are produced.
These would make a very nice basis for anyone who wanted crystals, 3D
snowflakes, etc.
Further deviations from the unit radius upon each facial subdivision would
likely produce some more interesting results.
All of these experiments - just give rise to more experiments :)
Post a reply to this message
Attachments:
Download 'subdivided_mesh_sphere.png' (94 KB)
Preview of image 'subdivided_mesh_sphere.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Also, if only _some_ of the vertices are normalized to the unit sphere radius,
> some very nice stellated / fractal shapes are produced.
Here they are - the basis array vertices are normalized, the face-edge midpoints
are not.
Post a reply to this message
Attachments:
Download 'subdivided_mesh_sphere.png' (94 KB)
Preview of image 'subdivided_mesh_sphere.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.08.2016 um 23:22 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
>> One thing is for sure: You've seriously screwed up on the icosahedron.
>>
>> Apparently you misinterpreted the positions of the individual points,
>> probably thinking that Phi<1, but in fact Phi>1.
>>
>> Swapping the 1's and Phi's in the TwentyHedron definition gives a nice
>> regular icosahedron.
>
> Are you just pulling my leg now?
> Because my definition of Phi is in the code, and when I comment out ALL of the
> vnormalize() directives, I get ... an icosahedron.
Then you must be using a different code than the one you posted. (Note
that the posted code doesn't actually show the icosahedron at all, only
the subdivided result.)
> And considering that the vertices are defined by ALL of the permutations of
> +/-1, 0, and +/-Phi, I don't see how "swapping" those values in any given vertex
> doesn't just give me ... another one of the points I already have.
It gives you the same set of vertices, but ordered differently, thus
giving you a different set of triangles.
> I'm going to add a little bit to my code to visualize the vertex normals of the
> smooth_triangles, because I'm having a devil of a time visualizing your
> description of how that all works at the moment. Your explanation of the
> situation is perfectly clear - the 3D result of that is just [for me] less so.
>
> Please also notice that there are a few green pixels in/on the lower left MESH
> icosahdron - the rotate y*180 degree instance. A small, but seemingly important
> detail, if using mesh{} is supposed to eliminate that problem.
No, the smooth_triangles issue is also present in (smooth) meshes.
> I haven't declared an inside_vector - could it be related in some way to that?
Nope, that's unrelated.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>These would make a very nice basis for anyone who wanted crystals, 3D
>snowflakes, etc.
I like the idea of a 3D snowflake. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Then you must be using a different code than the one you posted. (Note
> that the posted code doesn't actually show the icosahedron at all, only
> the subdivided result.)
<banging head>
Looking the two over, that must be true.
I've been squeezing in new work and edits as I can, and it's been hot as blazes,
and I can see how I might have lost track of what got edited and fixed. I
probably saw your correction and implemented it immediately afterwards as I was
coding the rest of the expansion macro.
Sorry. :O
I need better archiving and version control.
> It gives you the same set of vertices, but ordered differently, thus
> giving you a different set of triangles.
Yes, that makes sense.
That was a hard one to "see" and get ordered correctly without losing track.
I think I either need even _more_ practice at being able to see it all and keep
track of it in my head, or come up with a better way to rapidly visualize what I
need to do. But this was definitely a valuable experiment.
> No, the smooth_triangles issue is also present in (smooth) meshes.
But to a far lesser extent? Those few green pixels are present on the basis
array icosahedron. The smooth_triangle objects have a LOT more green present
even in the first two subdivisions. Only the third iteration seems to finally
get it smooth enough to be all red, since I guess the edges are finely divided
enough to overcome that effect.
Quite a nice demonstration of how simple it is to just instantiate a sphere{}
primitive and be done with! ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think a low res version, preferably with some slight scrambling of the
surface,
will be very useful for all sorts of stuff. For instance a spiral column, I have
done some quick testing, see the image. (I was supposed to be working... :p)
I used multiple objects inside the mesh command so that I could form a section
of
the column, ie a spiral. Which I then reused to make the column.
The columns are not smooth, and they are not supposed to be.
A scrambling/randomizing will make the surface uneven and remove the "pattern".
(I havent figured out how to add some random noise yet, only how to translate
the
"sphere" structure inside the mesh.)
Of course a smoother version will be useful for making a mesh of several
spheres,
that must be useful for doing architecture. (Ie saving loads of objects that
would require resources.)
Also, I think this should be faster than a blob for making a spiral. And the
blob
would have a smooth surface that would not be so easy to scramble/make uneven.
BTW is it possible to make a mesh solid and CSG subtract it from a box for
instance?
Best wishes, /A
Post a reply to this message
Attachments:
Download 'subdivided_mesh_sphere_tst2_r01.png' (1069 KB)
Preview of image 'subdivided_mesh_sphere_tst2_r01.png'
|
|
| |
| |
|
|
|
|
| |
|
|