robcat2075

Cloth rope can work, but you need to experiment quite a bit with it. The problem of using cloth as rope is to make it stiff enough that it doesn't collapse like a cloth fire hose when it rests on something and yet still be flexible enough to bend like rope. For I never found that happy medium. I had to simulate with cloth rope, then make a second rope model that was not cloth but had a bone for every spline ring and constrain every bone in the second rope to its corresponding spline ring in the original simulated cloth rope. However, in less-complicated situations pure cloth may function well. Here is a simple example case to get you started. [Mod edit: the several .mov files in this thread should all be playable in a common app like VLC Media Player that plays .mp4 files.] CordDrop.mov SimpleCordTest04_simmed.prj

It must be our current hair system because he mentioned using the various maps that can be used with it like density and direction.

I retrieved this c. 2004 work via the Wayback machine and felt it ought to be seen again. That's genuine A:M hair, expertly done. Great work Phil, where ever you are!

You'll have to tell me more. What are you trying to do?

I believe they can but I think their best use might be for heads which don't move much from their original location. Anything that ventures outside the bounds of the box jumps back to its undistorted position. If you tried to use a d box for an elbow you'd need the d box to also encompass the rest of the arm and hand. If anyone can show me to be wrong on that, that would be fabulous.

The image is a combination (done in an A:M Composite) of these two: The dark one has AO. For some reason I couldn't get either FakeAO or Real AO to get what I wanted so i tried combining two exposures. It's still not what I was aiming for. Then I blurred it by 2 pixels (also in A:M Composite) There is indeed a 2nd form, the white "seed" of the kernel. That was the tricky part to try to reproduce from the original photo. I made it blurry by sweeping the Index of refraction of the outer surface over a multi-pass render. Without that, the unsatisfying result is like this:

I think I have made one already. Check out this thread and there's a video tutorial down near the bottom in post #34. Probably. I am paralyzed by the task of trying to get it exactly right. The quicktime problem is a mystery to me still.

in the PWS, in the model, in Groups. Somethign is overriding something and needs to be moved above or below something else

Perhaps it's a groups priority issue. try re arranging the groups.

Here's a test of dropping kernals into cylindrical forms: CornDropA.mov

Haven't quite figured the cob thing out yet. Perhaps one might use the dupe wizard to arrange them in a cylindrical form first

A test to see if I could create the semi-random kernel arrangement by squeezing together cloth spheres. The first is with low "friction", the second is with high "friction": CornSqueeze.mov

I saw an article about this very unusual strain of corn that has multi-colored kernals and tried to see if i could make something that hinted at it:

I should add that you may well have to do that in v17, with its Simcloth "HiRes" switch ON. Test carefully.

Try this. You'll probably have to do more experimenting, it's just a bare test. jumponBox06h5_wider_cape_simmed_no_AO.zip

Just going back to the highspeed fps idea... here's 80 frames of footage shot in your original PRJ at 960fps and slowed down to 24 fps UniverseH900.mov

I looked at your universe PRJ. you just need a cloud of those particles to hang motionless? Set the velocity to zero and move the emitter to leave a trail of stationary particles behind it, then move your camera through it. No time tricks needed.

Baking particles at high frame rates has turned out to behave very oddly. Sidestepping that problem... with the PRJ set to 24 fps I made a camera move that went from 02:00 to 04:00 then squished that down to fit in 02:00 to 02:03 I set the PRJ to 480 fps and rendered from 00:00 to 04:00. That's 1920 frames I took the image sequence into AfterEffects as 24 fps footage and used Time Remapping to speed up the part that wasn't supposed to be slow FreezeH450.mov Using "Step" to avoid rendering frames i didn't need didn't work, i got jumps in the particle system where the time change happens. It's possible that further R&D with baking step might solve the need to render all the frames. But it can be done in a fashion, at least.

I've been testing out the high fps idea and I haven't been able to get the different fps sections to match without the jump in the particle system at the change over. Baking it hasn't helped yet either.

Set velocity to will only work if you want the sprite to remain at its place of origin. I did that for these clouds: http://www.hash.com/forums/index.php?showt...5&hl=clouds One way to "freeze" sprites that have been swirling around might be to temporarily render at much higher fps. If you want the sprites to freeze at 4:00, render at a normal fps up to 3:23, then in a new render set the fps to some high rate like 240 and arrange your camera move to happen in the next half second (120 frames). Render all this to an image sequence and play it at the normal 24 fps and the high speed section will be slowed down to appear time has stopped.

Here is one of my old test scenes updated to just use FakeAOGPU for interior AO: I think that's pretty good for 0.57 seconds! For comparison here are the tests from my previous thread of various AO schemes for interior lighting: The "jitter" version used 256 passes of a traveling light.

I'd have to say I don't think I've ever seen a knees-only leg on a character before. It's a novel idea, but I'm wondering how one would handle that in animation and if it would be unnecessarily distracting to the audience.

If it's the occlusion you're looking for, FakeAO can work real well in indoor settings. And it's fast!

Would love to, but I remember trying to request a feature somewhen in the past and wasn't "authorized" for some reason ?! Could someone point me to the feature request thread please? It will NEVER happen if you don't ask. Go to hash.com/reports like you do for bugs but mark the "severity" as "feature". I've asked for a lot of features over the years. Some happen, some don't. Since we already have Surface baking maybe it would be a matter of adding just one more map to the result? It's the only work around I can think of right now. What are you doing that needs radiosity?

Unless light maps work, (I can't even find them) there is no illumination baking. One way to approximate it would be to apply renders back through the camera onto the geometry, but you will need to do a render from enough angles to cover any sides of an object that will be seen. Illumination baking would be a good feature request, maybe for v18? Write it up and make a case for it. The old radiosity scheme did have a baking feature, perhaps it can be resurrected.