Jump to content

Alternative to Asset browser?


Recommended Posts

2 hours ago, srek said:

Cinema 4D assets can be stored transparently within the scene itself, can Lightroom do that? How does it handle multiple versions of the same Asset? 

Lightroom never touches my RAW-files, it keeps edits in a sidecar, a small ".xmp"-textfile containing all modified parameters, (It keeps the same edits additionally it it's central database, the "catalogue"). The benefit of the xmp is, that your edits can be very simply backupped or shared together with the RAW-file. It's also a form of redundancy for the huge (and I assume, complex, and therefore corruptable) database. 
A second version of the same RAW-file is simply a second .xmp-sidecar-file (a "virtual copy"). It takes up almost no space and it's shown very transparently as an "alternate version". So, in summary, it's a hybrid file+database-approach, that stores all changes parametrically without touching user files. I love that, that has been a good design foundation of lightroom since the very first version.
 

The analogy falls flat at your other question, as Lightroom of course only handles single photos, not "scenes" in the C4D sense. I'm not even exactly sure what you mean with "storing assets in the scene transparently", but I can think of no usecase (for myself) where this could outweigh the headaches concerning file-renaming etc. 

Again, thank you for the discussion. I hope you can see our point and maybe share our issues & thoughts internally? 

Link to comment

@keppnyou and @MJVkeep bringing up that the AB would change/touch/delete your original files, it just doesn't. If you drop one of your textures or any other file from a file browser into the Asset Browser this will create a copy and store it in the database you point it to. The original file is untouched and remains wherever it was when you dragged it!

The abbility to store assets within the scene is something that everyone who ever had to make sure that a project came with every texture, script or other asset used will find useful. If multiple people work on a bigger scene this ensures that they will never have issues with different versions of assets, filepath compatibility etc. Archiving projects with the exact version of assets that work is no big deal with this.

 

While i am not directly on the team that works on the AB, i do know that they closely follow the experience users have with it.

 

Link to comment

@srekyou're right, that statement of "AB changes my files" is imprecise and shortened. 

But let me explain my usecase of working with my asset-library, I hope it explains, where my problems come from. 

Over the years of working in 2D and 3D, I have built up a collection of assets that weighs 5.7 Tbyte
(it spans the usual stuff... 3D objects, VDBs, materials, HDRIs, preset-style scene-files, cached sims, etc., etc.). 
This library is like the backbone of my productivity. That doesn't mean, I'm just a "clipart-masher" -- often, I block out
things with the assets from my library and then continue to replace every single bit with "the real deal".

So, in order to efficiently work with this library, I frequently do the following things: 

  • add new assets
  • delete unusable stuff to de-clutter
  • rearrange folders
  • rename stuff
  • add meta-data (rating, comments, etc. -- (I do that with Adobe Bridge, that generates xmp-sidecar-files I mentioned above, too)
  • backup (+backup offsite)

So, this is my warehouse, and it's in perfect order. I have full control over the assets to do the things I described in the list. 

I can access it with every app; C4D's "Content Browser" was one of them. No problems - worked very well!

 

Now in comes the Asset Browser. 

 

I'd really love to use the Asset Browser, as it has some really cool functionality. Chris Schmidt's video on that was eye-opening. 

But I can only think of three scenarios with my usecase: 

  1. Copy all of my assets to AssetBrowser
    -- My original files are unchanged -- but now I would have to do all "housekeeping" twice. 
    -- I also would have double the footprint in terms of Terabytes. 
     
  2. Copy some of my assets to Assetbrowser
    -- This would somewhat mitigate the footprint problem
    -- But now I have a big warehouse next to a small one. 
    -- I would need to keep track of "where is what" and all the logistics that comes with that.
     
  3. Move everything to Assetbrowser
    -- Now my filenames are scrambled, metadata inaccessible and I would have to rebuild the structure
    -- I can't access my assets with other apps anymore. 

All scenarios are totally not working for me. And the frustration comes from being forced to use Assetbrowser. 
Why remove the Content Browser, when other almost-deprecated functions are allowed to linger on for years? 

tldr;
When saying "Ab scrambles my files!" it's short for: "I want to use the 3rd scenario, but can't." 



 

Link to comment

It seems that I work in exactly the same way as Keppn -  with a large and well organised 'warehouse', and i agree 100% with his post.

Fortunately I've stuck with R21 since the advent of the 'modern era', but from everything I've seen and read about the AB I wouldn't touch it...

 

My honest feeling is that there is a real disconnect between the people at Maxon who are developing these sort of features (let's call them 'the coders') and the people who have experience of actually working in CGI and using these types of tools in production.  It's almost as though the coders say, 'hey this would be a cool function / feature / approach!' but don't sufficiently understand or research or consider the implications for those who are actually going to use it.  IMHO this has been a problem at Maxon since it's inception.

Link to comment

I think that this new asset manager has the safety of maxons assets in mind. Maybe even a new revenue stream is planed with this. Where you can buy assets form some kind of store. I have the impression, that once more maxon interests where verry important, and the interests of the users baybe a bit less. I might be wrong, but i see a pattern there. Fortunately working with finder/explorer is a accepable way for me, but i am sad for all of those that are dependent of it. While i was always happy with the implementation of new features back in the days for me more and more newer features have some sort of academical feel to it. Just disconnected with the way many people work, implementing theoretically powerfull but hard or strange or unflexible workflows. Staring with team render server, over the overly complex material node system to the asset manager now. It feel much like discussing with my engeneering friends they often are so shure, that everyone thinks like them, while they basically just can talk to one another.

Link to comment
On 11/19/2021 at 5:34 PM, srek said:

@keppnyou and @MJVkeep bringing up that the AB would change/touch/delete your original files, it just doesn't. If you drop one of your textures or any other file from a file browser into the Asset Browser this will create a copy and store it in the database you point it to. The original file is untouched and remains wherever it was when you dragged it!

The abbility to store assets within the scene is something that everyone who ever had to make sure that a project came with every texture, script or other asset used will find useful. If multiple people work on a bigger scene this ensures that they will never have issues with different versions of assets, filepath compatibility etc. Archiving projects with the exact version of assets that work is no big deal with this.

 

While i am not directly on the team that works on the AB, i do know that they closely follow the experience users have with it.

 

As with keppen, you've seriously misread me here. Of course the original is not deleted or converted, no one is saying that. The problem is the creation and or duplication of a database on your hard drive that uses new storage space but where all the original metadata is lost and all the names are scrambled, as keppen said. Also bad is the fact that this database by default is in the operating systems app data storage location which is just about the most insecure and easily lost directory on any computer. Users should probably be forced to chose a proper data storage location before a single asset can be saved. Also the fact that the actual storage location and given name on disk is not learnable from within Cinema.  

 

2021-11-20_18-49-27.jpg

 

By the way, when I search the MaxonAssets.db directory on my hard drive, I can find lots of .jpg files but only one .c4d file. I'm guessing that means that c4d assets aren't saved as .c4d files but something else which is barely even identifiable or searchable by someone say trying to salvage something following some catastrophic system failure or something. 

 

Lastly, could you please explain more about the ability to store assets within a scene and how that is facilitated by the Asset Browser? I didn't understand that. How does that work? 

Link to comment
2 hours ago, Jops said:

I think that this new asset manager has the safety of maxons assets in mind. Maybe even a new revenue stream is planed with this. Where you can buy assets form some kind of store. I have the impression, that once more maxon interests where verry important, and the interests of the users baybe a bit less. I might be wrong, but i see a pattern there. 

Mabye there is a strong business allure to locking user's data (both offline and on) into a closed subscription business ecosystem, or maybe it's just a happy coincidence. Who knows. 🤷‍♂️

Link to comment

The AB excels at delivering and maintaining procedural assets. It allows for the seamless integration of hardcoded functions as well as procedural assets provided by Maxon, 3rd parties or the users themself into one workflow. While the Asset Browser encapsulates the storage and maintainance of the assets, everything in it is freeley accesible and useable. This is something fundamentally new to Cinema 4D and i can understand that some users don't have any experience with this kind of open approach to integrating functionality, but it is something that delivers a lot of power in a very easy to use way.

Regarding storing assets in scenes. If you created an own capsule asset that provides let's say a specific modeling function, you can copy that asset from your main database into the scene itself, thereby enabeling any other user who loads your scene to make use of the asset. The recipient can then also copy that asset into their own local database for use in other scenes. This is not limited to capsules but also works for basically every kind of asset you store into the AB, including bitmaps etc. Any asset used this way is only referenced by it's id, that stuff that makes the filename useless for humans, and is independent of any file paths or folder names, a big advantage when it comes to delivering scenes for rendering. All dependencies on assets can be resolved within the scene file if you want them to.

Personally i would prefer the use of shared databases in many situations, especially for the big stuff and if you work in regular groups of people, but there is no effective limit and storing assets in scenes has helped me distribute stuff for testing a lot already.
 

Link to comment
48 minutes ago, MJV said:

You said you can share all assets including textures, movie files and sound, everything needed to render the file In a single file but I still don't understand how that works.

If i understand right this means, that every asset, that you store as a asset in your database can be included into a c4d file, while assets that are not included in your database have to be handled the old way. @srek is this correct?

Link to comment
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • LATEST ACTIVITIES

    1. 16

      3D world #310

    2. 53

      Looking forward to the next C4D release

    3. 8

      CORE 4D Youtube channel

    4. 1

      Nodes Modifier result isn't updated anymore

    5. 8

      CORE 4D Youtube channel

×
×
  • Create New...

Copyright Core 4D © 2023 Powered by Invision Community