Community
Hi TF360, Fellows,
I have tried to familiarize myself with the new Body Sweep.
The at-hock generic test file is attached.
I did some basic macka-gee-gee with the new sweep option ... but with limited, if any, success.
Is it the final product? ... or is it just wetting a foot toe ... to check how deep it is?
Well, from my vantage point of view, it could be quite a drop from the standard sweep.
Regards
MichaelT
Hi Mr CADacombs, and other potential CAD_body_sweepers,
The short four weeks (since the foundation post) have passed faster than … the load time of complex assembly into the Fusion.
I used some of them to gather some 'substance' about functionality/features, which seems to be quite crucial in any adult CAD system, not to mention the Ultimate One.
Although intuitively simple, a BodySweep as a topological operation is quite convoluted when one tries to abstract it mathematically or put it in the reins of a numerical algorithm.
In 2D, such a sweep can be compared to a picture/photography blur or sticky shade following the object … just like one in foggy London depicted in "Dr Jekyll and Mr Hyde" by Robert Louis Stevenson.
It would be the simplest type of BodySweep. Other type? Let's imagine London's fog cut not only by such a sticky shade but also by its own shade curvature. Yes, I know it is hard to visualize … hence let's put this case to rest here .. and concentrate on the classical BodySweep.
Topologically:
The sweep of a point is a curve.
The sweep of a curve is a surface or a curve.
The sweep of a surface is a body or a surface.
The sweep of a body is a collection/conglomerate of … curves (edges), surfaces (faces), and bodies.
All of the above follows transformation governed by the sweep curve and, optionally, other auxiliary factors influencing body movement along/around the curve.
Suppose we represent the topological entities constituting a sweepBody (𝓼𝓑) as the set of abstract functions (in 2D,3D,..,∞D) and also the sweepCurve (𝓼𝓒) and auxMovement (𝓪𝓜) in the same way. In that case, we can devise a simple symbolic expression for the sweepBodyFeature (𝓼𝓑𝓕) as a function of parameter 𝓹 denoting the sweep phase.
Thus:
𝓼𝓑𝓕(𝓹) = 𝓼𝓑(.)⨂𝓼𝓒(𝓹)⨂𝓪𝓜(𝓹)
Where ⨂ denotes a more or less linear transformation operator with some bipolar logic. Thus, the abstract representation of the problem seems to be highly linear, indicating that its physical realization can be conducted in the main part with a significant degree of parallelism, offering at the same time accuracy and the reciprocal correspondence of topological entities.
At first, I approached the problem just as described above, but soon I realized that:
- The volume of the 𝓼𝓑𝓕(𝓹) grows very fast with complexity of 𝓼𝓑(.).
- The attempt to solve of 𝓼𝓑𝓕(𝓹) in the Fusion environment was like swimming in maple syrup, … sweety but slow.
- I have also made so many mischievous errors that would be enough to distribute them amongst the forum members, with something spare to put into my account in Dementia Bank™ for future use (the interest rate is high there … and it is growing).
- Therefore, … I put such an attempt at suspense … hoping that I will return to it … if I only remember.
- Because it is a promising approach, as it produces an 'error_less' topology outcome, with the promise of fast computing when implemented on the proper hardware.
It seems that 𝓼𝓑𝓕(𝓹) approach has been taken by Fusion Developers, offering the new Solid Sweep option. Obviously, they faced the predicaments mentioned above, and apparently (based on my limited click&play with the feature), the option is in an infant-matured stage.
One must notice that the resulting sweep body, as simple topologically as a cube, is 'lacerated'… like being lynched through a cacti field in Arizona by the CADboys. Fortunately (or not), they haven't managed to rotate the body. It could be even worse then … but perhaps this is the nature of 'the proper' topological sweep.
In the real CAD world, such a result would not make the Surface Sheriff happy if only he was aware of the lynch while happily patronizing the local Saloon by …
- Drinking Bourbon while in French Louisiana
- Drinking Whisky while in Yankee Territory
- Quaffing Hefeweizen while in Pennsylvania
- Sipping Gin in the New Amsterdam
- Drinking Tequila while in New Mexico
- Gulping an Okolehao in Hawaii
- Licking rum on ice while in Puerto Rico
- Shooting vodka while in Alaska … …
- and
- Watching a CanCan while in French Louisiana
- Dancing a Line Dance while in Yankee Territory
- Whirling Schuhplattler, while in Pennsylvania
- Clog dancing while in the New Amsterdam
- Watching a Flamenco while in New Mexico
- Enjoying a Hula Dance in Hawaii
- Swinging La Bomba in Puerto Rico
- Dancing with Bears while in Alaska … …
Where have you been … Mr Trippy Lighting?
But, hey, …. Let's go to the actual substance before … some Northmen get berserk.
How can we approach the sweep body problem more pragmatically and feasibly?
Get back to Mr Hyde … at the crack of dawn, pushing his body through thick London's fog. For Dr Jekyll, a fog closes behind his body, but not for Mr Hyde; it creates a tunnel the fog droplets can not penetrate. Hence, we have the answer to how to distinguish between body (Dr Jekyll – good gay in the daytime) and sweepBody (Mr Hyde – nasty side of himself) … the next step is to vectorize, discretize (walking steps) and code the process as a feature in Fusion. It is so simple, isn't it?
The process somehow integrates the progressing along a path body in tangential directions of segments intersecting it. It is done step by step, practically abstracting from the detailed topology of the object; only its projection is essential. The numerical discretization will introduce errors dependent on the size of a step taken and the underlying object's topological characteristic to a lesser extent. The algorithm can be parallelized to a significant degree. Another vital aspect is … that if you visualize the fog tunnel sweeped by Mr Hyde … it is very smooth!!! It is what Surfce Sheriffs like the most!
There is still one important question. How do you move (sweep) the body along the path?
Careless lynching, yankeeng (hard yakkang in Aus.) … it is not right. We are in a CAD environment, and everything must be predictable and repeatable. Fusion introduced the terms parallel, perpendicular, and aligned (new one), but it is not enough to cover even a small portion of body movements along paths that real life can throw at us. I have met a sympathetic rabbit who (which) has a more diverse imagination!
Thus, how do you describe such movement … methodically?
For the simplification of things, we put aside some singularity issues.
Let's look at the path as a coordinate system generator. The 3D orthogonal system will be our favourite here. Each parametrized point on the path can be associated with three vectors: normal, tangential and their cross-product. In a natural way, they give us a coordinate system anchored to the specific path's point. Call these coordinates N, T and C, but there is more; we can add global (and also local component's) coordinate axes, e.g. X, Y and Z, to the set. Combinations/permutations of these axes can be assembled into a transformation group.
A transformation group founded on four axes seems to be natural for a sweep along a path.
A transformation group founded on five axes seems to be natural for a sweep along a surface …. Why not?!
Think as The Path imposes on surrounding its space its Own Identity, or set of laws/rules/twists&kinks … just like laws of physics … imprints on our 3D+T space … generating not-so-obvious hyper-dimensional curvature(s). The beauty of the CAD system is that we can design our own twists&kinks and even change them based on our ingenuity or the opposite of the latter. We are in charge; we do not need to succumb to external, exa-natural influences. Well, … let's ignore them then!
The number of algebraically/topologically permittable combinations/permutations of a group of four vectors out of set {N, T, C, X, Y, Z, …} is staggering … which is proof that there are some smart rabbits out there.
The practical realization of such a transformation group is a transformation matrix denoted above as 𝓪𝓜(𝓹) where 𝓹 is a parameter along a path (or other arbitrary function … e.g. 𝓽𝓲𝓶𝓮(𝓹)).
What would be typical, observable SweepBodyModes?
- Parallel – The camera is on a perfect gyroscope, always facing in the same direction. In essence, a point on the path borrows the camera's coordinate system.
- Aligned-curvatured – a rabbit runs along a curvy path, aligning its body axes tangentially, normally and what the cross-product vector dictates.
- Aligned_δ(xy) – a sober man waking along a curvy path, aligning his shoulders axis to the path's normal plane and keeping a Z-vertical position
- Aligned_δ(zyx) – a not-so-sober man waking along a curvy path, aligning his body to the path's Z-extruded wall and keeping himself as close as possible to his perceived Z-vertical position
- Put your interesting body movement mode here !!!
The visual examples below cover the tip of an iceberg possibilities only. The body progression can be abstracted into two phases. At first, the body (component) inherits a path's local coordinate system. When attached, the transformation group mechanism takes over. In the presented examples, only rotations of the respective local axes are shown where the angles α,β,γ correspond to gyration around the first, the second and the third axis (which only in specific circumstances relate to the global coordinate system) while the forth axis θ is associated with the path's tangent vector, although not synonymous with it in the general cases. The process's algebra is relatively straightforward but requires delicate, alert attention. In general cases, one can introduce scaling or/and translation. With these, the whole system becomes very complicated, not necessarily algebraically… but to the external observer … it could be you. Spinning one's head about such a realization could be close to impossible. Even the rotation by 180 deg around θ, as in the second part of the video, can significantly strain the neck. I was conscientious not to extend the range here. I hope that 180 degrees … is just right.
What about the more complex than cube topologies?
Well … I have had a dream … but the resource I wanted to use …. escaped. Nevertheless, I will not give up … and take severe action soon!
What is the status of the SweepBodyModes project?
Based on self-assessment, it is not even in the infant stage. I would describe it as a delicate foreplay, touching the subject at different angles and learning the responses. I am an experienced developer, so I will rest for a while until I bring back escapee to the project and then pause before … getting into too much trouble. I don't reject the idea of approaching the problem from a different angle in the future, though… but only if the desire persists.
Attached files:
SweepBodyModes_A_arcd.jpg 4K_stereo ( 0.4MB) https://a360.co/4cqSIOf
SweepBodyModes_A_mono.png 4K_mono ( 3.6MB) https://a360.co/45vekak
SweepBodyModes_B_mono.png 4K_mono ( 4.0MB) https://a360.co/3z7ZVof
SweepBodyModes_C_mono.png 4K_mono ( 2.6MB) https://a360.co/3yYrGiU
SweepBodyModes_mono.mp4 4K_mono (47MB) https://a360.co/3VtgEK9
SweepBodyModes_arcd.mp4 4K_stereo (88MB) https://a360.co/4coWgko
SweepBodyModes_Bodies.f3d F3D (10MB) https://a360.co/3zfiZAP
To be viewed on 4K media devices (monitors, UHD TVs, projectors...) of reasonable performance. For the best experience, use stand-alone media applications (WMP, VLC) and the native resolution 3840x2160 - full screen. The '_arcd' files require an anaglyph red/cyan glasses, while '_al' is for active shutter glasses 3D hardware (~30 deg viewing angle is recommended). Download the files over a network, where the cost of doing so is not a concern. The files are to be used for private, non-commercial purposes only.
Regards
MichaelT
P.S.
Sorry that the post is so long. It was not my intention at the start … but it just happened … naturally!
Hi Potential CAD_BodySweepers,
After the successful comprehension of Escepee – Banny Th'Stanford as per announcement:
https://forums.autodesk.com/t5/fusion-design-validate-document/warrant-notice/td-p/12869745
I put him (it) on the BodySweep test run. For some who might be nervous, … still in the SkinOnCondition … although I have had some thoughts about chopping the top of his ears, which are the main contributors to the respective body sweep topology errors. For the faint-hearted, I decided for the time being to apply the stringent integration criteria only … a significant additional cost on my compassionate half … but almost unbearable to the rest.
As a compromise, we agreed that the Bunny would yank the sweep run without any rewards … and later on, we might give him some vouchers exchangeable for CADrots rations of sizes depending upon our perception of his contribution to the ultimate Fusion Greatness.
And one more thing ...
The Banny Th'Stanford will be held in the special security cage ... of the finest Hollywood technology.
Perhaps he (it) will be safer inside than out...
Cont'd or not Cont'd ... this is the question?
Postface:
You might notice some "error" artefacts in the first part of the video.
They are of two types. The Cyan or Magenta Bunnies are in the pre-race positions, not aligned with the track's intrinsic vectors. Therefore, they do not contribute to the sweep error.
The second type is moving hairy lines over the sweep body surface. They are symptoms of errors … but of what value? Those errors can be infinitesimally minor… and still visible on the screen.
It stems from how rendering mechanisms (of opaque) geometry work. At first, graphic entities are projected to the planes parallel to the screen plane. In the second, the results are sorted depending upon their distance to the screen. The most distant entities are rendered first (physically drawn on the screen canvas), while those with a "negative" distance are ignored.
It is a very simplified picture; in reality, the process is much more complex.
This basic (and highly perfected software/silicon algorithm) mechanism shows that even infinitesimally small distances between entities can result in rendering artefacts.
Attached files:
StanfordBunnyModes_A_arcd.png 4K_stereo (5.5MB) https://a360.co/3LicfFq
StanfordBunnyModes_A_mono.png 4K_mono (3.4MB) https://a360.co/3Lddplv
StanfordBunnyModes_A_arcd.mp4 4K_stereo ( 32MB) https://a360.co/3Wpmoqd
StanfordBunnyModes_A_mono.mp4 4K_mono ( 18MB) https://a360.co/4cvkzNL
StanfordBunnyModes_A.f3d F3D ( 3.6MB) https://a360.co/3XVAHnn
To be viewed on 4K media devices (monitors, UHD TVs, projectors...) of reasonable performance. For the best experience, use stand-alone media applications (WMP, VLC) and the native resolution 3840x2160 - full screen. The '_arcd' files require an anaglyph red/cyan glasses, while '_al' is for active shutter glasses 3D hardware (~30 deg viewing angle is recommended). Download the files over a network, where the cost of doing so is not a concern. The files are to be used for private, non-commercial purposes only.
Regards
MichaelT
Forums Links
Can't find what you're looking for? Ask the community or share your knowledge.
Post to forums
