Pixar's Universal Scene Description Now on Pypi | Hacker News Reader

Pixar's Universal Scene Description Now on Pypi

pypi.org

173 pointsdagmx20 comments

> Pipelines capable of producing computer graphics films and games typically generate, store, and transmit great quantities of 3D data, which we call "scene description". Each of many cooperating applications in the pipeline (modeling, shading, animation, lighting, fx, rendering) typically has its own special form of scene description tailored to the specific needs and workflows of the application, and neither readable nor editable by any other application. Universal Scene Description (USD) is the first publicly available software that addresses the need to robustly and scalably interchange and augment arbitrary 3D scenes that may be composed from many elemental assets.

https://graphics.pixar.com/usd/docs/index.html

This history section of the docs gives some good context

https://graphics.pixar.com/usd/docs/index.html#Introductiont...

The Github source is more useful: https://github.com/PixarAnimationStudios/USD

The reason I shared the PyPi link is that USD is quite a massive build, and this is the first time an official prebuild of the library is available courtesy of Pixar and Nvidia.

I must say the new build scripts on GitHub work really well now. Our Lab build is built via these scripts. It's also on vcpkg as well if you use that.

For those curious, this also works in Blender: https://docs.blender.org/manual/en/latest/files/import_expor...

Seems to be export only though

This may not be what Pixar intended, but I see USD as a format for me to export from an editing application (when I’m done) and consume in an AR-based iOS application. If I want to buy and integrate an asset into something I’m working on, I prefer to use .blend files (although I’m willing to settle for FBX and OBJ).

USD is an interchange format and runtime. It's meant to preserve as much of the scene as possible as you go between different applications and allow for parallel editing.

Houdini is a great example of this.

But yes, you can also just use it as a last mile format. Though that's certainly not the main purpose

I can't help wondering when this will be ported to Go. Doesn't performance matter in such a sophisticated technology?

From the FAQ:

> USD consists of a set of C++ libraries with Python bindings for scripting.

I also can't help but wonder, since when is go considered a performance oriented language :)

I think people see python as accessible but not very fast. Then they see Go which is fairly accessible but with significantly better performance than python. Why not use Go instead?

What people don’t realize when they make that comparison is that the python version of many popular libraries is a light wrapper over a bunch of C++ (or some other really fast language).

At least that’s what I figure is going on. I see a lot of people wanting to port stuff to Go.

Having said that, Go is awesome for bespoke solutions where you don’t have some python bindings on a C library to do what you need. It’s certainly not a slow language, and its tooling is exceptionally nice to get started with.

But what I want to know is when are they going to port PyQT to Go?

> I think people see python as accessible but not very fast. Then they see Go which is fairly accessible but with significantly better performance than python. Why not use Go instead?

Most (all?) 3d graphics programs use python as an extension language so they'd have to re-architecture their whole system to use Go programs in place of python. If it's even possible to dynamically load Go programs without having to resort to an Inkscape level of tomfoolery where the extension is called as a separate program and all the data is passed as shell arguments.

...not saying anything is wrong with Inkscape's way of doing things but I sure wish it had a built-in python api.

Don't make claims about performance without measuring first. Don't push a language without measuring first. Don't push a language without comparing its performance with similar workloads. Don't make assumptions about performance based on the language.

You seem to be trying to come across as if you know and care about performance, but your comment actually proves you still have a long way to go.

If you care about absolute speed then Go isn't generally the best choice. You're looking at Fortran/C/C++ (depending on the application) and maybe Rust if you can take a bit of a performance hit. Of course, most performant Python code is actually Fortran/C/C++ with a thin wrapper so you get the best of both worlds.

Unless you are a physicists there are very few Fortran libraries used from Python.

Don’t the linear algebra libraries used by numpy (blas and lapack) use fortran? That’s the case for R, I thought it was for numpy also.

I thought SciPy used Fortran for some things?

python is the front end, a language that most Technical Artists use and know well. If you look at the core libraries behind this you will see some really good modern C++, including other libraries such as OpenImageIO, OpenColourIO OpenSubDiv etc all of which are C++ (including SIMD and CUDA routes for most).

Reply on news.ycombinator.com