#Explode w/elements
17 messages in this thread
Gary, (and others)
Is there a way to use the Explode IPAS, such that it maintains the shape of the
elements within the "boxed object"?
In other words, instead of the source object being broken into randomized
triangles (tweaking min and max variables), I'd rather have the source object
maintain its "element" definitions.
I have tried tweaking min and max faces to attempt to match the number of the
faces in the elements, but the explode function seems to disregard these
settings in some circumstances.
For example, I can explode a collection of spheres, and the spheres will
maintain their individual shapes, however, if I attempt the same process with a
bunch of more complicated elements (popcorn) it doesn't work.
Is there a modified (or updated) version of Explode that will honor the shapes
of elements in the source object being exploded? Or has someone developed a
technique that will achieve the same thing?
Thanks,
-Jeff
Jeff, you need to read the 4th paragraph in the Tips section for explode on
page 26 of the manual again. If you set your min and max fields to the same
number as your popcorn, it'll explode it into perfect element-sized chunks.
Just make sure that each of your popcorn elements has the same number of verts.
– G
Gary,
But what if the elements don't have the same number of faces….<G>?
I guess I'll have to rebuild them…
Thanks,
-Jeff
I'm sure that you were looking for something to do, anyway….
– G
Gary,
Even after rebuilding the popcorn elements with the same number of faces, I
still have the same problem.
It turns out that if you build elements for the explode from the Editor, i.e. a
sphere or a box, etc., explode (honoring elements) will work exactly as
prescribed in the manual.
However, as soon as you perform a boolean operation to one of those basic
elements, i.e. subtract a sphere from a sphere to create a "moon" shaped
object, the explode will no longer honor the element construction. Everything
seems to get triangulated…..
Is there something about boolean that is affecting the integrity of an
"element", thereby confusing the explode? Is there an easy way around it?
I have a sample that I could upload to you if you wish….
Thanks,
-Jeff
Of course, if you boolean an object, you have the choice of welding the
subsequent elements or not. If you DON'T weld them, it'll never work. You've
got to choose to weld them.
Now, if you do weld them, you're still going to screw up the face list enough
(by booleaning) that you might have to do a Select/Face/All and a
Create/Face/Detach [Selected] to pull the ojbect into one contiguous face list.
At that point, get the number of faces and plug that into the min/max fields in
Explode and you should be fine. If not, I'd skip the boolean step and just use
other tools like Fractalize, Displace, Crumple, etc to make your popcorn.
– G
Gary,
Looks like detaching faces and rebuilding the face list won't work either. I
even went so far as to .DXF out the faces, load them in AutoCAD, blast them
apart even further there and .DXF them back to 3DS to have 3DS rebuild
them……no go!! Welding (even to large tolerances) doesn't seem to improve
the situation.
What is it about the face list in a non-booleaned element that makes it stick
together as compared to a booleaned object? The weird thing is that the
booleaned element behaves as it should with all the other 3DS commands (i.e.
move, detach, etc.). I think it must be problem with how explode works with
the elements/face lists……but what do I know?!?
We're trying to build a rather detailed popcorn kernel and deform, fractalize,
etc. will be fairly difficult to manipulate for the procedure. Boolean was
working so easily. We'll probably have to assign keyframe motions to kernels
individually……sounds like a job for R4 Scripting…
And all this seemed so "elementary"……<g>
Later,
-Jeff
P.S. if you've got any other ideas, I'm willing to try almost anything…
Ahh… another mystery of life. A mystery to be lived, it is.
– G
If you want to, send me a couple of the kernals and I'll see if I can get it to
work.
There shouldn't be reason that a booled object will fail in this process. (plus
I love both pop-corn and puzzles)
J-me
Hi Jamie,
I could send you the kernels, or you could build a "problem" object by simply
taking two intersecting spheres and boolean subtracting one from the other.
Attach this boolean object to a "box" for the explode command and voila, an
explosion that won't honor the face MIN/MAX values.
If you detach the "problem" object from the explode "box" and replace it with a
simple sphere, voila, an explosion that DOES honor the face MIN/MAX values.
Just remember to query the proper number of faces from the object before
attaching.
I have also noticed that if you use displace.pxp and tesselate the base object
(i.e. a simple sphere), this will also destroy the integrity of the element.
However, if you take a simple sphere and delete some manually selected faces
from it, it will still work with explode's face MIN/MAX values.
This is truly bizarre.
If you could determine a process that will make this work, I would be very
grateful…..I don't feel like applying (& copying) motion tracks to a bucket
full of popcorn….. Oh, BTW, I need to record this on Friday….<G>!
Thanks very much for offering your assistance!!
-Jeff
P.S. If you'd still like a "kernel", I'd be happy to oblige.
Jeff,
Did you try detaching each element from the object and then
Create/Object/Attach each one to rebuild the object?
An object in 3DS is a numberd list of vertices. If you attach two objects
together, the second object's vertices get added onto the end of the first
objects. This gives two sets of vertices each of which is contiguous and each
of which defines an element. If you boolean the first element, some of its
vertices will stay the same and some new vertices will be created. These will
be added to the objects vertex list after vertices for the second element.
This interleaving of vertices is probably what is screwing up Explode. Explode
is just going down the vertex list for the object grabbing x number of vertices
at a time. If the vertices are interleaved then Explode has to pick up parts
of each. _Any_ editing of the mesh after it is assembled has the potential to
interleave the vertex list. If you have rebuilt the object by attaching
separate objects as elements, their vertex lists should be contiguous.
Does this sound right to you, Gary?
Terry Gilbert
Forcade & Associates
It sounds plausible, Terry… but you'd have to test it to be sure.
– G
Hi Tim,
I understand what you're saying about two objects being joined together,
resulting in a single object with more than one element.
Unfortunately, the problem appears to be deeper than that. What I'm refering
to is a single object that contains a single element. If the object/element
has been created using any boolean procedure, it results in a garbled face list
(or vertex list?) to EXPLODE.
Jamie Clay, confirmed this situation with me last night. The simplest example
is to create two G-SPHERES (each with 256 faces). Move the spheres so that
they intersect each other. Do a boolean subtract, using the two spheres (with
weld on) to create a single sphere with a "bite" taken out of it.
So here we have a single object, consisting of a single element and x (varies)
number of faces and vertices.
Attach this single object/element to an Explode bounding box and you will find
that even after using the correct face min/max values to match the object
you've attached, explode will create various particles out of the object.
I hope this explains the problem a little further. I've tried all sorts of
methods of detaching and re-assembling the faces to build an "ordered" mesh,
but nothing seems to work. Perhaps EXPLODE should just have an "element" mode
button added to it (just below FACE Min/Max).
Later,
-Jeff
I just don't think it's possible to explode an object into elements once you've
boolean'd it, because the face list becomes reordered into an arbitrary order
after the boolean op.
– G
I really don't know…. It just seems so strange that 3DS core functions can
understand the element vs. object logic of objects built using boolean
functions, but EXPLODE doesn't follow the same logic.
I'm outa town for the next couple of days, but when I get back, I'll upload a
sample file for you that should explain the problem. As I mentioned, Jamie
Clay understands what I'm talking about on this and has confirmed that indeed,
this will NOT work….for unknown reasons.
It's not an issue for this case any longer, but it would be nice to know if
there is a different way to handle it in the future.
Thanks,
-Jeff
Not so strange, really. Explode doesn't know anything about elements vs
objects… it only understands face lists. And the boolean function just
orders the face list in a totally arbitrary way.
– G
Ahhhh,
This is beginning to make sense for an explosion that has many elements within
the EXPLODE box, however, I still don't understand why if you have a single
element (built via booleans) of say 256 faces inside of the EXPLODE box and you
have MIN/MAX both set to 256, why this single element will get blasted into
various triangles.
Whereas if you have a single G-sphere of 256 faces as the element in the
EXPLODE box, this item will remain intact.
Regardless, at this point it doesn't matter anymore; we've used a different
method….
I'm just curious (if you can discuss it), will the K-Frame scripting in R4 be
able to handle this type of motion for a group of objects/instances? Judging
from the feature lists, etc., I would suspect it can. If it can, I humbly
accept the challenge….
Later,
-Jeff