[eric nixon]

Cant get this to work, are there any rules to follow? or is it just bugged.

It renders but the results are chaotic;

[JDHill]

Blur for particles is done internally by the MaxwellParticles extension, based on the shutter speed of the active camera. It works fine in my tests here, so I can't really speculate on the nature of any issues you may be running into, and would therefore suggest starting with something simple and working up from there. On a very basic level, what happens is that the plugin hands Maxwell sets of points and vectors from Cinema, which describe the particle positions, velocities, and so forth.

[eric nixon]

I kept trying but got nowhere, so i built a stupidly simple scene (attached) and it still doesnt work?

http://www.mediafire.com/download/7oga3 ... e_test.c4d

Any ideas?

[JDHill]

The first problem is that you're talking about particles, but using volumetrics. In which case, the main factor is that you're not exporting velocity (i.e. Maxwell Volumetric > Extra Magnitudes > Load Velocity), which means there are no vectors available to the extension for calculating blur. Start with the scene you uploaded, and try these steps:

• - Delete your Scene, Camera tag, and Volumetric tag.
  - Add a new Scene, and a new Volumetric tag.
  - Assign a dark red lambertian material to the Particle Geometry.
  - Enable Volumetric > Extra Magnitudes > Load Velocity.
  - Set Volumetric Density Multiplier to 100, and Min. & Max. Density to 10.
  - Set Volumetric Shutterspeed to 10

You may need to bump the camera EV to 15 and move the camera around a bit to get a clear view of what is happening, but once you do, then experiment with setting Volumetric > Shutterspeed anywhere between 5 and 20, and/or with setting Motion Blur Multiplier between 0 and 2.

[eric nixon]

Its working, thanks for the help.

Got too say its a tricky beast to learn, (settings can cause out of ram type crashes, and voxelization slowdowns, and slow renders too - maybe due to density?)

But its pretty cool too, kind of tempting to play with this...

Just random renders of the same particle cloud, (give or take a few frames),..just blindly trying out settings;



Should 'max density' be renamed to 'max particle visual depth' or something like that? I may be misunderstanding what it does.

Sorry JD I just realised these arent C4D specific musings anymore..

[JDHill]

Yep, I can't say I know much about actually working with the extension itself.

[eric nixon]

Sorry more q's

From the docs;

PARTICLE BASED:This type of volumetric will create density based on particles, either loading a particle file

can I load a file from within c4d? how does realfow c4d plug handle this?

This resampling mode is too crude for smoke + dust, but it is a good technique for fluffy clouds using very few initial particles with extras...


EDIT: aha.

RF Particles Importer

So therefore no alembic or krakatoa in c4d? just realflow..

[JDHill]

Not necessarily just RF -- you can put a volumetric tag on a null, set the Field Type to Particle, and assign any file supported by the (MaxwellVolumetric) extension using the File Name parameter:

"Particle based" - this lets you use a particle simulation to define the volumetric density. You can either use particles directly in supported applications (such as Maya, 3ds Mac, Cinema4D, Softimage), or load an external particle file in several formats (.abc, .bin, .pxy, .prt, .rpc).

[eric nixon]

Thanks, that sounds promising, I will try to find a way to convert the Turbulence/TP files into something readable.

Thanks again.

EDIT:found a link showing tp > alembic, looks like perfect workflow.

http://vimeo.com/46776463

[eric nixon]

Well I managed to export an alembic (kind of) but then I noticed that the volumetric still does the voxel resampling thing, even with a file.

Whats a bit frustrating is that my smoke sim is voxel based to begin with

Would be awesome to point the vol tag to the turbulence cache file... one can dream right?

[eric nixon]

This is from Houdini maxwell plug, This looks the business! I'm wondering whats different about the houdini plug volumetrics compared to c4d plug?

[JDHill]

MaxwellVolumetric is a Maxwell extension, so there is nothing "different" about volumetrics in any plugin. However, it takes input data to generate output; the extension can only work with what it's given, and it's possible that there are more types of particle attributes in one platform than another. In Cinema, we read ID, Radius, Position, Velocity, Age, and Mass from the Cinema particles; there are, however other channels available in the extension, some of which would be present when using a RealFlow simulation, but they're not present in Cinema. Looking at the Houdini plugin docs, it looks like that plugin supports using RealFlow files (or .abc, .pxy, .prt, .rpc, like the Cinema plugin does, when the volumetric tag is put on a Null), as well as a "Voxel Field" translated from Houdini objects.

[eric nixon]

Ok, thanks for explaining whats up.

Perhaps in time, with the integration of Houdini code into C4D, 'Voxel field' will be an option for us too, Or perhaps Maxon will buy out TFD eventually.

Anyways I'll park my particle studies for now, theres no point in learning stuff I cant use, as I will only forget it.

The whole particle workflow re. x-particles, TFD, and cinema is too elaborate right now. It needs more integration to be competitive. I just wonder if Maxon have plans to fix this mess, probably not

[Aniki]

Well regarding TFD support for Maxwell Volumetrics, I tried to get that integrated but there was no interest from NL back then.
TFD will eventually either output to Field3D or, more likely openvdb, so if the volumetric object could support that, we were back on track.

I appreciate the tests you did, but am waiting for a proper solution, so we can render different colors/absorptions/emissions etc based on the actual voxel fields.

[JDHill]

Well regarding TFD support for Maxwell Volumetrics, I tried to get that integrated but there was no interest from NL back then.

That is not an accurate statement; you asked me about it prior to the release of V3, and I told you that it was not my place to comment on unreleased features. Any decision to interpret that as meaning there was no interest would have been yours; for my part, I only considered the question as being inappropriate.

The fact of the matter is that it has long been in my plans to see about supporting TurbulenceFD (support for X-Particles has also been requested, as was support for RFRK, which was only recently finished in the 3.0.5 build), but that focus on support for third-party plugins, where possible, cannot supersede integration with Cinema itself, which of course is itself a moving target, for example with regard to the new Cinema R16 material model, which is my current focus. To my way of thinking, at least, this is the proper approach: to prefer automatic interoperation between unrelated components (e.g. Maxwell & TurbulenceFD) by means of open standards (as you say, openvdb/etc), but also to try to add direct support, time permitting, where that is not possible, or is not likely to materialize.

That said, I believe you will find no prior mention of the above until this very post, since I generally try to avoid commenting much on potential future developments; I consider it as being more respectful to customers to talk about such things only when they're done, or when I'm 100% sure they very soon will be, rather than go promising things willy-nilly, when it's not yet known if they can be done, or how much time it will take. I only write this here, at this time, to point out that there is a big difference between there being "no interest" in something, and that thing not yet having been promised.