Some issues regarding caching
#1
Hello, Tyson!
Thanks again for doing all the stuff you are doing! Smile

I've come across multiple issues with caching and would like to know if you are aware of it.

1.)
When I Input a relative path after I previously have chosen a path via the "..." button, it will cache into the wrong directory.
So If I chose "C:\temp\cache\tycache\file.tyc" via the "..." button and then after that change the string in the edit field to a relative
 path like ".\cache\mycache.tyc", then it will cache into the wrong directory, but I do not understand the exact behavior in my case it
 was suddenly saving it to "C:\temp\cache\cache\tycache\cache\mycache.tyc - but I don't know why exactly. 

When I delete the cache node, then create a new one, then input the relative path directly, it works fine.


2.)
I render all my projects with V-Ray Standalone. Having said that, the usual goal for rendering is to "outsource" as much animated geo 
as possible into Standalones supported caching formats like abc and vrmesh so that V-Ray does not dump all this info as text into the 
vrscene files on export, resulting in huge vrscene files.

Now I'm sure that V-Ray standalone does currently not have a plugin that can interpret Tyflow caches directly and I'm sure it's very 
low prio on the to-do list if it is on there at all. Wink

So, I've tried the different export methods from tyflow (Vrmesh and alembic) and came over multiple issues:

Alembic: I export an alembic file via "export particles" node, then I import that abc file via the VrayProxy loader, 
the normals are usually flipped and the material IDs are gone, and it looks like the velocities are not exported correctly.

Vrmesh:
In my test, the vrmesh export was doing nothing, not creating a file, just popping up the message box "Vray Proxy export complete!"

3)
After these tests I thought I could just use the "regular" vrmesh exporter or the "regular" alembic exporter on a TyCache object.

The problems are:
Alembic:
It does not export animation at all and does not export material IDs properly when I load the abc via VrayProxy

Vrmesh:
Vertex animation looked okay! It also export the material IDs correctly but apparently velocities are not exported to the vrmesh file.
When I import it via VrayProxy, it does not show motion blur. (the shell feature in the "tearing" section is off).

Additional info:
If I use the vrmesh exporter on the tyflow object (not the tycache object) it the velocities are actually 
exported correctly as well as the material IDs and pretty much everything else. Smile


Sorry for the long text but I wanted to include as much info as possible, attached to this thread you will find the scene I used for doing these tests.

Again, thanks for doing all this.
-Robert


Attached Files
.max   TyflowDebug.max (Size: 1.5 MB / Downloads: 221)
  Reply
#2
Hi Robert,

1) Until now I haven't officially supported relative paths specifically....could you elaborate on the behavior you'd expect? Is the relative path you type in something you expect to be saved to the output filename box? Or just a shorthand way of navigating in the file save window? For example, if I navigate to "c:\tyflow\export\files\" and then type my save location as "..\thefile.vrmesh", once the save file dialog closes the path that appears should be "c:\tyflow\export\thefile.vrmesh", correct? Sorry, I just don't work with relative paths very often...

2) My alembic exporter doesn't directly support velocity export (yet)....that's further down the todo list once I develop a unified velocity system for tyFlow for all the different interfaces I support (max has no internal idea of 'vertex velocity' prior to version 2019, so it's a nightmare trying to pass the data around to every renderer and export format). For non-changing topology most renderers should be able to interpret geometry even without those velocity values, but I see you're doing lots of cloth tearing so that I imagine that's the issue...

As for normal flippage and matIDs missing...make sure your proxy loader is set to display full geometry and not preview geometry. I get the visual artifacts you described when in preview mode but not in full mode, when I preview Alembic exports from tyFlow in a VRay Proxy object within max. Also make sure you're using the latest build since matID export support was only added in v0.16041.

As for vrmesh not exporting anything...I did some testing and it seems like the issue is that the export method I'm using now gets mad when there are unescaped special characters in the path (like if your path is "c:\files\test" it interprets the "\t" as a tab), so that will be fixed in the next build. In my current test once I fixed that, your file exported from the Export Particles exporter to a .vrmesh file just fine....and in your write-up above you have lots of "\t"s, so I'm guessing that was the problem.

3) I can't speak for Max's built-in Alembic exporter because unfortunately Max's current Alembic implementation has a bunch of bugs and limitations (it doesn't correctly support matIDs on changing topology, for one)

The vrmesh exporter having all the correct data makes sense, since ChaosGroup is good at writing working code Smile
  Reply
#3
Hey Tyson,
thank you for the quick reply! Smile Sounds great, I'll wait for the next build.

Thank you
-Robert
  Reply
#4
Did you see my question regarding #1? I edited my response a bit and perhaps you saw it before I finished editing...
  Reply
#5
Hey Tyson,

regarding the relative paths, I would expect that ".\" is the global variable "maxfilepath". I like to do this with bitmaps and phoenix caches as well because this way you can easily move max projects around between people that have something like Dropbox on different mount points. This way they do not have to relink their bitmaps all the time.

Regarding the file windows file dialog, I do not expect any different behavior.

Thanks again for taking so much care!
-Robert
  Reply
#6
Ah I see, so the actual relative path is what would be saved as the output path...

I'll make a note to do some testing and get that working.
  Reply


Forum Jump: