"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'