This primarily asking Bill to comment briefly.

I was attempting to use the meshrelief macro recursively.  That is, to
apply textures to objects already generated from the macro.  The results
suggest that the meshes generated have their normals reversed more or 
less randomly and about evenly.  Does that make sense?  Before I dig 
into the code too deep, would it be correctable, or is there something 
inherent in your approach that would prevent it?  At first glance it 
would seem to be related to the order of the parameters in the cross 
product, and that, I am guessing, is related to how you develop the 
spiral of points?

-Jim

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:
> I was attempting to use the meshrelief macro recursively.  That is, to
> apply textures to objects already generated from the macro.  The results
> suggest that the meshes generated have their normals reversed more or
> less randomly and about evenly.  Does that make sense?

Do you mean that the shading is randomised on an otherwise geometrically correct
final mesh, or are the final vertices mangled as a result of moving the surface
inwards and outwards randomly on the second pass?

I shall investigate, at any rate. :)

Bill

Post a reply to this message

Bill Pragnell wrote:
> Jim Charter <jrc### [at] msncom> wrote:
>> I was attempting to use the meshrelief macro recursively.  That is, to
>> apply textures to objects already generated from the macro.  The results
>> suggest that the meshes generated have their normals reversed more or
>> less randomly and about evenly.  Does that make sense?
> 
> Do you mean that the shading is randomised on an otherwise geometrically correct
> final mesh, or are the final vertices mangled as a result of moving the surface
> inwards and outwards randomly on the second pass?
> 
> I shall investigate, at any rate. :)
> 
> Bill
> 
> 
I will post and image and code

Post a reply to this message

Hmm.

Well, I think I know what's causing the normals to get scrambled. The vertices
generated for the second pass (before deformation), by tracing onto the first
mesh, appear to fall precisely on the first mesh's vertices. There must be some
rounding error introduced at these points that sometimes flips the direction, so
that the subsequent deformation goes randomly inwards and outwards.

The scrambling does not occur if the first object is rotated slightly (or,
presumably, if something other than a sphere is used as the inner object, thus
moving the first mesh's vertices off their original radii). Another workaround
would be to use slightly different resolutions for the two passes.

Interesting bug! Perhaps I can introduce a random rotation factor in the macro
to allow for this, based on the resolution parameter.

Hope this helps

Bill

Post a reply to this message

Bill Pragnell wrote:
> Hmm.
> 
> Well, I think I know what's causing the normals to get scrambled. The vertices
> generated for the second pass (before deformation), by tracing onto the first
> mesh, appear to fall precisely on the first mesh's vertices. There must be some
> rounding error introduced at these points that sometimes flips the direction, so
> that the subsequent deformation goes randomly inwards and outwards.
> 
> The scrambling does not occur if the first object is rotated slightly (or,
> presumably, if something other than a sphere is used as the inner object, thus
> moving the first mesh's vertices off their original radii). Another workaround
> would be to use slightly different resolutions for the two passes.
> 
> Interesting bug! Perhaps I can introduce a random rotation factor in the macro
> to allow for this, based on the resolution parameter.
> 
> Hope this helps
> 
> Bill
> 
> 
That was easy! Thanks! I will use a small rotation. I did sort of think 
of that in a confused way, but my response, to alter the resolutions 
between passes, did not eliminate all of the coincident situations. Duh! 
  Meanwhile it was instructive to be pulling apart your very useful code.

I could get the results I want with isosurfaces, but again, their speed 
is not improved on my new, eight-thread, processor.  But mesh is!  I 
think these macros of yours are invaluable.

Jim

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:
> I could get the results I want with isosurfaces, but again, their speed
> is not improved on my new, eight-thread, processor.  But mesh is!  I
> think these macros of yours are invaluable.

Glad to be of help! The motivation behind the macro was primarily speed, not
flexibility, so it sounds like you're the target user base ;-)

Bill

Post a reply to this message