On 31/07/2025 21:44, Chris R wrote:

>>
>> Thanks for digging this up.  I am thinking I will try and implement this method
>> as an alternative using my own coding style, POV 3.8 features, and fitting into
>> my library code framework, and then compare the results with the triangle-based
>> version.  It appears there is some interesting code to deal with the problem of
>> local, small plateaus on the surface object to try out.
>>
>> -- Chris R
> I wrote the code based on the letter stacking code in libcollide.inc and
> debugged it, and added the grid generation piece to my libmesh.inc library.
> Here are the results of repeatedly adding 20 discs to the same uneven surface
> using the algorithm.  I think it does pretty well and it's actually quick enough
> that you could run it during rendering, but I kept the option to write the
> transforms to a file so you can pre-create them.
> 


Hope that help a little...


-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Chris R" <car### [at] comcastnet> wrote:
>
> > I wrote the code based on the letter stacking code in libcollide.inc and
> > debugged it, and added the grid generation piece to my libmesh.inc library.
> > Here are the results of repeatedly adding 20 discs to the same uneven surface
> > using the algorithm.  I think it does pretty well and it's actually quick enough
> > that you could run it during rendering, but I kept the option to write the
> > transforms to a file so you can pre-create them.
>
> Damn, that is nice.
>
> I'm hoping to see a pile of many more primitives on a much more uneven surface!
>
> Nice work!
>
> - BW

Coming Real Soon Now...

I plan to add documentation to the library code files and create a usable sample
scene using them as an example.  In the mean time, I can create a version of
this scene with additional object types and I can pervert the surface as well.

-- Chris R

Post a reply to this message

"Chris R" <car### [at] comcastnet> wrote:
> In the mean time, I can create a version of
> this scene with additional object types and
> I can pervert the surface as well.


This sounds far more exciting than simply perturbing the surface!
Perhaps a saucy image_map?
I can't wait to see what "additional object types" you'll use . . .  ;)

Hopefully the sample scene doesn't perturb anyone too much.  :D

- BW

Post a reply to this message

"Chris R" <car### [at] comcastnet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Chris R" <car### [at] comcastnet> wrote:
> >
> > > I wrote the code based on the letter stacking code in libcollide.inc and
> > > debugged it, and added the grid generation piece to my libmesh.inc library.
> > > Here are the results of repeatedly adding 20 discs to the same uneven surface
> > > using the algorithm.  I think it does pretty well and it's actually quick enough
> > > that you could run it during rendering, but I kept the option to write the
> > > transforms to a file so you can pre-create them.
> >
> > Damn, that is nice.
> >
> > I'm hoping to see a pile of many more primitives on a much more uneven surface!
> >
> > Nice work!
> >
> > - BW
>
> Coming Real Soon Now...
>
> I plan to add documentation to the library code files and create a usable sample
> scene using them as an example.  In the mean time, I can create a version of
> this scene with additional object types and I can pervert the surface as well.
>
> -- Chris R

Documentation, official sample scene, and posting of references to the GitHub
repo for this code are still TBD, but here is another sample after some updates
to the code.

The original author had code that would verify the difference between the 3
found support points and the surface beneath them are within a given threshold.
After staring at the code for a long time, I believe the first two contact
points should always end up directly on the surface, but it's possible the 3rd
one could be off due to the distance estimation from the surface being a linear
projection onto the X-Z plane, but the transformation is a rotation, which means
the final object point gets rotated onto the plane, not projected.

To cover this, the author, for his scene, would check the distance and would
jitter the object a bit if it was too large and then try again.

In my code, the layout only makes one attempt, but I return the 3 resting points
for the object and the surface as part of the transformation result.  In my test
code, I check to see if the max distance is higher than my threshold and do the
jitter of the object there to get a better position.

The results are pretty good, even with the bumpier surface I am using now.
Resting spheres on each other still results in unstable-looking structures,
(unless the spheres are covered with super-glue...)

I will get to work cleaning and documenting and let you know where you can find
the code and how to use it.

-- Chris R

Post a reply to this message

Attachments:
Download 'libcollide_test.png' (193 KB)

Preview of image 'libcollide_test.png'

"Chris R" <car### [at] comcastnet> wrote:
> "Chris R" <car### [at] comcastnet> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> > > "Chris R" <car### [at] comcastnet> wrote:
> > >
> > > > I wrote the code based on the letter stacking code in libcollide.inc and
> > > > debugged it, and added the grid generation piece to my libmesh.inc library.
> > > > Here are the results of repeatedly adding 20 discs to the same uneven surface
> > > > using the algorithm.  I think it does pretty well and it's actually quick
enough
> > > > that you could run it during rendering, but I kept the option to write the
> > > > transforms to a file so you can pre-create them.
> > >
> > > Damn, that is nice.
> > >
> > > I'm hoping to see a pile of many more primitives on a much more uneven surface!
> > >
> > > Nice work!
> > >
> > > - BW
> >
> > Coming Real Soon Now...
> >
> > I plan to add documentation to the library code files and create a usable sample
> > scene using them as an example.  In the mean time, I can create a version of
> > this scene with additional object types and I can pervert the surface as well.
> >
> > -- Chris R
>
> Documentation, official sample scene, and posting of references to the GitHub
> repo for this code are still TBD, but here is another sample after some updates
> to the code.
>
> The original author had code that would verify the difference between the 3
> found support points and the surface beneath them are within a given threshold.
> After staring at the code for a long time, I believe the first two contact
> points should always end up directly on the surface, but it's possible the 3rd
> one could be off due to the distance estimation from the surface being a linear
> projection onto the X-Z plane, but the transformation is a rotation, which means
> the final object point gets rotated onto the plane, not projected.
>
> To cover this, the author, for his scene, would check the distance and would
> jitter the object a bit if it was too large and then try again.
>
> In my code, the layout only makes one attempt, but I return the 3 resting points
> for the object and the surface as part of the transformation result.  In my test
> code, I check to see if the max distance is higher than my threshold and do the
> jitter of the object there to get a better position.
>
> The results are pretty good, even with the bumpier surface I am using now.
> Resting spheres on each other still results in unstable-looking structures,
> (unless the spheres are covered with super-glue...)
>
> I will get to work cleaning and documenting and let you know where you can find
> the code and how to use it.
>
> -- Chris R

Last update in this thread.  I added documentation and an example .pov file
using the new macro and committed the code to:
https://github.com/carath63/povlibrary

Given the way I write code, you will end up needing a lot of the files in the
library folder, so just check out the whole thing from GitHub.  The relevant
files to look at for this are:
1. Examples/collision_grid_test.pov
2. library/libmesh.inc
3. library/libcollide.inc

The two main new macros are:
1. Mesh_grid_surface_create - for scanning an object and creating a mesh of
points for its top or bottom surface.
2. Col_rest_grid_on_surface_transform - for taking the grid created by
Mesh_grid_surface_create and finding a transformation that rests it on a surface
object.

A couple of notes: The result of calling Col_rest_grid_on_surface_transform is a
dictionary representation of an SDL transform.  The code for creating and
interpreting this dictionary is in library/libstringify.inc.  The macro adds an
additional entry to the dictionary containing the 3 points on the object and the
3 points on the surface that were used to create the transformation.  This is
what I use to nudge the object around the surface if the transform does not
result in all three points touching the surface.

-- Chris R

Post a reply to this message

Attachments:
Download 'collision_grid_test.png' (120 KB)

Preview of image 'collision_grid_test.png'

"Chris R" <car### [at] comcastnet> wrote:
> This is
> what I use to nudge the object around the surface if the transform does not
> result in all three points touching the surface.


Have you seen?

https://www.youtube.com/watch?v=47YbLU7-J1M

This reminded me of that.
Perhaps you can find some inspiration or use for this in this or other of your
projects.  :)

- BW

Post a reply to this message