FORMAL COMPLAINT

[jtmsf]

The quotes are from http://render.otoy.com/forum/viewtopic.php?f=34&t=45718

I have MODO 801 and Just bought Octane. Am I reading this thread correctly? "MODO 801 API doesn't support accessing particles", and that's it?! I have to buy MODO 901 to have OCTANE rendering particle sources for Replicators?! So it's an impossibility for 801 users? This is a BIG problem.

The Modo API version that I use for Modo701 & Modo801 doesn't allow a plugin to access particle positions. However the Modo 901 API /does/ provide access to particle data. So your understanding is correct. And with the 901 API it is only providing the particle position, but not the age or size, so it's not perfect (yet). I only added particle data access very recently, so it's new functionality that hasn't been fully tested by users yet.

In modo, It's possible to directly connect the csv point cache node to the replicator's particle source input. If octane can't read the "internal particle data", isn't there a way to get octane to read the CSV sequence and then instance the geometry (all inside MODO 801)?

Maybe. However all this is covered by the Modo901 API, so I'd rather not embark on adding a new feature to the 801 version of the plugin which can already be done by the 901 version - given I would expect the vast majority of Modo users to upgrade to 901 in the near future. I'd rather spend that time developing new and exciting functionality to benefit all users.

So in summary, I think your best option is to update to Modo901.

Paul

As I said, I just bought OCTANE and MODO Plugin. I didn't buy “OCTANE for non-901-MODO”. OTOY should state clearly in the products description that prior to MODO 901, the particle/replicator functionality does not work, and that it will NEVER WORK because OCTANE as no intention of implementing it prior to 901 (MODO 901 was just released).

Don't get me wrong, I'm not saying that this strategy is Your responsibility. But as I understand, You are part of the team responsible for the development of MODO's plug-in. And You stated that You'd “rather spend the time developing new and exciting functionality to benefit all users” (901, of course), than spending time to “embark on adding a new feature to the 801 version of the plug-in which can already be done by the 901 version”

Did anyone at OCTANE made a market research that concluded that “the vast majority of MODO users will upgrade to 901”, and that those users would buy OCTANE RENDER? And the rest of the users that ALREADY use OCTANE with MODO? No attention will be given to them? One thing I can confirm, at the present, the overwhelming majority of users do not use 901. How many 801, 701 users with octane are there? And of those, who will upgrade to 901?

I think MODO users should be very worried about OTOY's customer support and product devolopment, I am!

If knew this three days ago, I would not buy OCTANE RENDER.

[LFedit]

"The Modo API version that I use for Modo701 & Modo801 doesn't allow a plugin to access particle positions."

It says right here "The Modo API" It is modos fault.

I understand you just bought the plugin but you have no idea how far this plugin has came in the last 6 months and it will only extend further. If you did your research a little better you wouldn't have had the problem because this has been talked about (the api and 801 limits) a bunch of times on the forums.

[face_off]

I am sorry to hear of your disappointment. The non-support of particle positions in Modo701/801 is nothing to do with the plugin - it's a limitation of the Modo API.

How many 801, 701 users with octane are there? And of those, who will upgrade to 901?

I am unaware of any Modo701 users, which means that almost all Modo701 users upgraded to Modo801. And I would expect the same for Modo901.

Paul

[abstrax]

There is a demo version of the Modo plugin which you could have tried before you buy. That's why we go through the effort to provide a demo version in the first place to allow you to evaluate the product before[.i] you buy.

[jtmsf]

I "played" with the demo for a week prior to buying. It's impossible to do a proper test because it doesn't support rendering animations.
So, now that the "having tested the demo" issue is clarified, can You please tell me what prior-901 users can expect from the development team?

I'm having a lot of issues with particle generators, for example (not emitters, generators). I created a scene with a particle generator, particle modifiers (pmods) and replicators and it renders OK. But when I start to animate pmod channel values nothing happens.
Another example: using animated falloffs to mask static particle distribution: it renders OK the first frame but it doesn’t animate the moving falloff.
Another limitation is animated texturing. I know it works in other plug-ins, but in MODO I can't seem to get it to work.


Thank You

[face_off]

Most of your questions are answered in the animation section of the manual. http://render.otoy.com/universe.php#42R ... Animations. So untick "Load All Frames into Octane", and if you have animated textures, tick "Reload Materials Each Frame". The animation system is being improved every release, so if you have a specific situation which is not animating correctly - pls send me the scene and I will take a look. For Modo901 users, TF are fixing the vertex motion blur bug, so the plugin should be able to do that too - but that will not be fixed Modo801.

You please tell me what prior-901 users can expect from the development team?

The plugin will support Modo701, 801 and 901. Any change to the plugin which is applicable to all 3 versions will be released for all 3 versions. For example, the next release enabled he live updating of shared material nodes (as per http://render.otoy.com/universe.php#42S ... 0Overrides) and that will go out for all 3 versions. But Modo901 specific changes will obviously not propagate down to 701/801.

Paul

[jtmsf]

Thank You for Your help.

I already asked this, but I'm reformulating the question (sorry to insist)

In modo, It's possible to directly connect a csv point cache node to the replicator's particle source input. The external csv file that's created by modo has all the particle data. If octane can't read the "internal particle data" why don't You (modo's plugin develpment team) get octane to read the external CSV sequence and then replicate the geometry accordingly. This would allow Modo 801 and 701's users to get particle working on octane. If there is a way, you should explore it.

In the CSV file there is the following information about the particles:
ptcl.id
ptcl.pos.X
ptcl.pos.Y
ptcl.pos.Z
ptcl.vel.X
ptcl.vel.Y
ptcl.vel.Z
ptcl.age



Thanks

[face_off]

In modo, It's possible to directly connect a csv point cache node to the replicator's particle source input. The external csv file that's created by modo has all the particle data. If octane can't read the "internal particle data" why don't You (modo's plugin develpment team) get octane to read the external CSV sequence and then replicate the geometry accordingly. This would allow Modo 801 and 701's users to get particle working on octane. If there is a way, you should explore it.

In the CSV file there is the following information about the particles:
ptcl.id
ptcl.pos.X
ptcl.pos.Y
ptcl.pos.Z
ptcl.vel.X
ptcl.vel.Y
ptcl.vel.Z
ptcl.age

I'm sorry, but the time/cost required to do this is not justified by the benefit, when users could simply update to Modo901. If you want to do this yourself, export the scene from Modo to OCS using the plugin, load the OCS into Octane Standalone, then load the CSV file into a Scatter node. You will need to convert the Modo Point Cache CSV file to the format required by Octane (1 row of 12 floats per line representing each point, the 4th, 8th and 12th float being the pos.X, Y and Z respectively, and the 1st, 6th and 11th float being 1.0).

Paul

[jtmsf]

Thank You for the info, Paul.

As a customer with MODO 801 and Octane MODO plugin I complained about OTOY's "apparent" lack of interest in developing a solution that would benefit non 901 users. However being a customer that values the excellent quality of the product that is OCTANE, I have to respect OTOY's strategy regarding MODO plugin development. You're allocating your limited resources (resources are always limited) on developing features using 901 API. Continuing with this exchange-of-opinions is pointless. Thank you for the feedback.

As a workaround for non 901 users please tell me if this workflow for getting particles working on OCTANE standalone is correct:
in MODO we have to:
Make the animation and then export the particles CSV file
Export all objects in Alembic file format inside Octane's plugin

In a spreadsheet software: convert CSV from MODO's "format" to OCTANE's "format"

In OCTANE Standalone: Open Alembic and plug the OCTANE's CSV to the "Scatter Node" (Can we use sequential CSV files for the particle animation in OCTANE standalone?)


Thanks

Joao

[face_off]

Joao - depending on how you value your time - I think upgrading to Modo901 will be cheaper than going via CSV. But if you insist on the CSV option, the workflow would be:

1) Export each particle simulation to a separate CSV
2) Convert the CSV to Octane format (as described above). Yes, you can do this in a spreadsheet, and such a spreadsheet was posted 12 or more months ago here (by Rappet). You will need to convert the CSV file for every frame of the animation
3) Load the scene in Modo into the Octane Viewport and export to OCS
4) Load the OCS into Octane Standalone, locate the mesh you want driven from the particle simulation, add a Scatter node between the Mesh and the Geometry Group and load the CSV - render, load the CSV for the next frame, render, etc. This can be automated via LUA

The other way this may be possible is to select the Replicator in Modo and Bake Geometry Cache. It won't bake the animation - but it may do what you need.

Paul