Thinking Particles

#1321

test FX shot for fun, made in free time… hope you like it, FX guys… :wink: Made with TP, fume and krakatoa
i’ll make some making of soon
https://vimeo.com/60734197

#1322

Cool! :slight_smile: How does it work?

#1323

nothing too complex actually, just TP particles scattered on sphere and rdial force with turbulence, triggered by radial texture maped on direct light)

#1324

Hello , since this is my 1st time here I apologize in advance if i am posting this at the wrong place and request to direct me to the proper place to post this … if not … then here is my problem as follows:

I am fracturing a geometry procedurally in TP4. Since max cannot create geometry and/or delete them automatically the “export” operator puts all geometry in the scene from the beginning and associates an animated visibility track with each object (i.e fragment). So only when an object breaks into pieces the fragments’ visibility turns on and the parent’s visibility turns off.
Now the problem is I want to take the fragmented objects to real flow to do further work and i cant find a proper way to get rid of those additional hidden geometries from which the fragments are derived. Secondly I found out that the fragments which are initially invisible (due to visibility is turned off ) are animated from frame one even before the main object is fragmented. Where they are supposed to stay put until a colliding object hits them. Since these are animated in such a way which i dont understand why before their visibility turns on I am unable to use them in other simulations.
However they act the way they are supposed to just when the animated visibility turns on. So even if am able to select and get rid of parent objects from which the fragments comeout … still cant use these fragments since they are the position and rotation keys are animated unusually before then visibility turns on.

  Ah big post ,, but i wanted to make sure am clear enough .. any advice on will be highly appreciated.
#1325

I’d go with prefragged pieces, animate in TP, add the RF sim and then do one more fragmentation when the RF is done, so you skip the whole problem.

#1326

is it me or there is a big issue with frostMX and TP?

evrything works good until i start using geom instance in tp,
on workstation it works good, but it cannot render on farm, kinda annoying

#1327

Does it work when you PRT cache it? Are you using frost for the meta shape or the instanced shapes?

#1328

i guess it will work with ptr, i’ve already tested various options, and easiest workaround is to cache tp sim and load sim to new empty tp setup

here is sample file if u want to check it on network rendering:
it will work on your work station, and will fail to render via backburner:)

anyway im sure its a frost bug:)

https://www.dropbox.com/s/mu4ms6o5k8ojt7t/frost_BUG.max?m

ps. love yr dvd’s , make next one about some math tricks in TP, like using matrix in tp5 etc… :wink:

#1329

Thanks :slight_smile:

Well I don’t have network setup at home, so I can’t try that, but yeah, it looks alright locally. You might wanna XMesh the frost locally and then use that for the rendering.

#1330

Has anyone experienced a bug / issue with TP where caching starts to take way more time than usual?

I’ve got a scene which was caching as expected, but for some reason it now produces huge cache files, and takes about 20x the amount of time to cache.

I’ve dropped all my volume breaker settings to test levels, and can now almost scrub the scene in realtime in the viewport, but the same scene takes 2 hours to cache?

I’m wondering if my only option is to rebuild the scene in a new file and hope the same issue doesn’t happen again.

This is only a test, but concerned if this happens in production it could be a real problem.

#1331

Caching to a network location can yield the symptoms you describe. Check that. If that ais the case, cache locally and then move the cache to the network. The cache read from the network isn’t an issue.

Cheers

#1332

thanks for the reply - yeah, this is a local cache. Have plenty of drive space too.

#1333

Well, caching of TP is always slower than viewing it in viewport, as I heard, while caching TP can only use 1 core due to max’s core limitations. Did not check it though.

But if it was okay, and then at some point started making huge files and all… Did you increase samples per second too high? Thats the main reason to make cache files larger, from what I encountered. As well as the number of particles of course.

#1334

That’s not true :slight_smile: Preview is simulation + display, caching is simulaiton + display + file write. The file write, with the typical TP cache sizes, is not slow, unless you’re going over network. The display is often quite slow, with heavy sims. You can turn off viewport update while caching, from the master dynamic. And the simulation part takes the same time.

#1335

Thanks, Glacierise, myth busted =)

#1336

Ok, stocked with one problem from some weeks finally I found the problem but not the solution:

I have particles with an animated material on it (blend material that goes from vraylighMtl to VrayMtl). With a Material time and age of particles connected to “material time”. When its suposed to have the vraylightmtl my particles are transparent.
After a lot of time I figured out that the problem is the vraylighmtl with “materialtime” node. If I change the vrayligtmtl for a vraymtl is working fine. If I disable “material time” and create a static vraylightmtl also shows fine, but both is not working.

Anyone has a workarround for this?

(My workarround right now is to render one pass with vraylight (without animation), a pass with vraymtl (withou animation) and an animated pass from white to black animated, but will be cool something more direct.

#1337

You should report this, I’ve seen people complaining about the same problem before.

#1338

Long time no see guys,

Hey have you guys come across a deep compositing solution in max yet? Vray or Final Render.
I’m doing more personal work and I’m salivating to get my hands on a solution.

Nuke has the tools but the renderers seem to be behind.

#1339

I think I read something about the next VRay being able to do it, but I’m not really sure.

#1340

UHHHHG! It can’t come soon enough. Ive found some stuff on google that guys are using some sort of vrst reader. But they must be doing beta shit.

I don’t know if you’ve used it but it is the biggest thing to happen to fx in a really long time.
It’s so nice to comp particles over a volume and see them blend and occlude properly. No more comp tricks or complex layers.

Max is going to be crazy if it gets that shit. TP + Fume + deep comping. Probably the fastest fx combo out there. Can’t wait.

All what max needs is a FLIP solver after that and I will be very very happy.

-Andrew