3 ms·

> It is not meant to be used inside a DCC app, as-is. > If you import data of this complexity into a DCC app your workflow is broken/you are doing something wr

> It is not meant to be used inside a DCC app, as-is. > If you import data of this complexity into a DCC app your workflow is broken/you are doing something wrong. are you sure you're not just saying this because years of software being slow made people cargo-cult workarounds around the issue which are now assumed to be "the way" in the field ?

orbital-decay 4y ago
The software is fast where it's needed - it makes the right trade-offs. There's little point in building IDEs capable of handling terabyte-sized source files, because just having a terabyte source file is ridiculous. Scenes like Moana are not intended to be handled as a whole, they are assembled from little pieces - semantically independent and assignable to different people with different skill sets. It's not the matter of software performance, it's the matter of process organization.
- HelloNurse 4y ago
  At some point, the little pieces need to be assembled, reviewed and finally rendered. Why wouldn't you do that with the DCC application rather than with specialized, limited tools?
  - virtualritz 4y ago
    Indeed, you often do that "somehow" inside the DCC. But again: the DCC doesn't see the high detailed version of that geometry in a proper pipeline. It only sees a proxy. See my detailed reply above. Only the renderer does see the final geometry and even that may be generated procedurally, on demand. I.e. stuff like fur, particles or the like is often generated on the fly since caching (and then reading) this data is not only impractical but also may be slower. Think a terabyte of fur data for a horde of fluffy monsters on screen (per frame, of which there are 24 per second of film at least) that needs to be distributed to each blade on a render farm or, worse, machines in the cloud (again and again since each frame goes through many revisions in lighting/rendering before its final). Computing the fur from a few hundred thousand 'guide hairs' on each character, on the fly, is a better approach.
- slavik81 4y ago
  The Blender OBJ loader was incredibly inefficient. Blender used something like two orders of magnitude more RAM than necessary, so even a small model would take gigabytes. It was basically useless for any model of even modest complexity. Working around its limitations was dozens of hours of effort when I was importing and rendering my own procedurally-generated models. I was seriously considering rewriting the Blender OBJ importer myself. Ultimately, I ended up writing an OBJ to Alembic converter, since Blender handled those more efficiently.
virtualritz 4y ago
> are you sure you're not just saying this because years of software being slow [...] Yes. And I don't know where to even start explaining this. Don't get me wrong. "Simply put": there is no use case for this. Moana e.g. has gazillions of vegetation geometry instances. Why would you have those inside a DCC? Pebbles on the shore, etc. etc. VFX pipelines are specialized. An animator does not care if there are 10 million hairs on their furry character while they do the animation. A lighter only cares to see the fur when it's rendering, not while operating the light rig in the DCC. Modern pipelines have instant feedback/viewport rendering where proxy geometry is swapped out for "the real thing" by the renderer (or a custom plugin inside the renderer) on the fly. The result, inside the renderer, is something like the Moana dataset. Hence its publication. It's a stress test for renderers, not DCCs.
- jcelerier 4y ago
  > "Simply put": there is no use case for this. there can't be for now, because artists couldn't realistically do this. I've been working with artists for, what, close to ten years now and I can guarantee you that their use of the software permanently fills the performance increase that such software gives. That's like saying, why would a music sequencer need to support more than, say, 100000 tracks, which sounds ridiculous until you see someone actually coming up with a fun music score that leverages generative scripting to create very cool pieces
  - virtualritz 4y ago
    The performance increase is eaten by scene complexity. This is and has been the norm since the advent if CGI in blockbuster movies, in the 1970's. For every order of magnitude that hardware gets faster (and/or software gets 'better', i.e. using better parallelization etc.), image complexity in your average shot increases by an order of magnitude. So yes, what artists are doing is more complex but relatively so. I.e. it doesn't invalidate anything I and others wrote about the case in point – the Moana asset, how such assets are built and what part of a VFX pipeline reasonably ingests them.

orbital-decay 4y ago

The software is fast where it's needed - it makes the right trade-offs. There's little point in building IDEs capable of handling terabyte-sized source files, because just having a terabyte source file is ridiculous. Scenes like Moana are not intended to be handled as a whole, they are assembled from little pieces - semantically independent and assignable to different people with different skill sets. It's not the matter of software performance, it's the matter of process organization.

HelloNurse 4y ago
At some point, the little pieces need to be assembled, reviewed and finally rendered. Why wouldn't you do that with the DCC application rather than with specialized, limited tools?
- virtualritz 4y ago
  Indeed, you often do that "somehow" inside the DCC. But again: the DCC doesn't see the high detailed version of that geometry in a proper pipeline. It only sees a proxy. See my detailed reply above. Only the renderer does see the final geometry and even that may be generated procedurally, on demand. I.e. stuff like fur, particles or the like is often generated on the fly since caching (and then reading) this data is not only impractical but also may be slower. Think a terabyte of fur data for a horde of fluffy monsters on screen (per frame, of which there are 24 per second of film at least) that needs to be distributed to each blade on a render farm or, worse, machines in the cloud (again and again since each frame goes through many revisions in lighting/rendering before its final). Computing the fur from a few hundred thousand 'guide hairs' on each character, on the fly, is a better approach.
slavik81 4y ago
The Blender OBJ loader was incredibly inefficient. Blender used something like two orders of magnitude more RAM than necessary, so even a small model would take gigabytes. It was basically useless for any model of even modest complexity. Working around its limitations was dozens of hours of effort when I was importing and rendering my own procedurally-generated models. I was seriously considering rewriting the Blender OBJ importer myself. Ultimately, I ended up writing an OBJ to Alembic converter, since Blender handled those more efficiently.

virtualritz 4y ago

> are you sure you're not just saying this because years of software being slow [...] Yes. And I don't know where to even start explaining this. Don't get me wrong. "Simply put": there is no use case for this. Moana e.g. has gazillions of vegetation geometry instances. Why would you have those inside a DCC? Pebbles on the shore, etc. etc. VFX pipelines are specialized. An animator does not care if there are 10 million hairs on their furry character while they do the animation. A lighter only cares to see the fur when it's rendering, not while operating the light rig in the DCC. Modern pipelines have instant feedback/viewport rendering where proxy geometry is swapped out for "the real thing" by the renderer (or a custom plugin inside the renderer) on the fly. The result, inside the renderer, is something like the Moana dataset. Hence its publication. It's a stress test for renderers, not DCCs.

jcelerier 4y ago
> "Simply put": there is no use case for this. there can't be for now, because artists couldn't realistically do this. I've been working with artists for, what, close to ten years now and I can guarantee you that their use of the software permanently fills the performance increase that such software gives. That's like saying, why would a music sequencer need to support more than, say, 100000 tracks, which sounds ridiculous until you see someone actually coming up with a fun music score that leverages generative scripting to create very cool pieces
- virtualritz 4y ago
  The performance increase is eaten by scene complexity. This is and has been the norm since the advent if CGI in blockbuster movies, in the 1970's. For every order of magnitude that hardware gets faster (and/or software gets 'better', i.e. using better parallelization etc.), image complexity in your average shot increases by an order of magnitude. So yes, what artists are doing is more complex but relatively so. I.e. it doesn't invalidate anything I and others wrote about the case in point – the Moana asset, how such assets are built and what part of a VFX pipeline reasonably ingests them.