Hacker News new | ask | show | jobs
by MAGZine 1048 days ago
This is a big deal. I used to work at Autodesk, trying to build software that made 3D blueprints available to everyone, everywhere. Rendering things on mobile is hard, in part because you need to writer bespoke renderers, and in part because the data formats for the assets are not aligned.

Pixar developed USD, and it should really help to standardize 3D tech. In particular, I hope that USD can help make it easier to build high-performance rendering tech for a variety of applications that might not receive so much attention from the 3D graphics people (this is one thing video games do quite well, from a CS approach!)

Having some big names behind the standard should help, but of course, the proof will be in the pudding as to how meaningful their contributions are, and how much their involvement pushes the adoption of the standard.

3 comments

> Rendering things on mobile is hard

I don't know. You can stream Unity to mobile with the service I've authored (https://appmana.com/watch/theheretic for an example).

Looks nice. However the issue with all 3d streaming I've ever tried is latency. It's great if you're near the server. Terrible if you're far away.

It's hard so say what the input latency is for the head demo you shared. I guess about 100ms, which is totally fine for a mostly static scene with simple orbit controls.

However I also tried out the Lebron James vs Father Time game. Input latency is over 1 second so it's not playable. Any time I touch the screen it freezes for a second then jumps to the new location.

You might like this one more - https://appmana.com/watch/virtualtestdrive - because it's just better :)

While of course I want latency to be as low as possible, the difference between 100ms and 500ms of latency doesn't register in the engagement metrics for these experiences. For millions of laypeople, it doesn't seem to matter that much. However, going from 670ms of time to first image (this service) and 2.5s (worst case) increases bounce rates by as much as 5 percentage points. PureWeb, which typically takes 35s to load, isn't suitable for any mass audience at all.

So imagine downloading a USDZ file for some AR thing. It's real, it's something people try to do. But the bounce rates on those experiences are insane, I don't know why Niantic funds them, there isn't anything you can do about it. There isn't a future for "it takes a while to load" on phones. That's the real constraint.

I’m not sure what the issue is, that whole scene was rendering in what I would consider seconds per frame rather than frames per second.

I have an iPhone 13 Pro and a decent internet connection and if I came across that I would bounce out immediately.

It's called "virtual test drive" but is it really just a turntable of a car?

I tried a bunch of keyboard commands and nothing happened. Can I test drive the car?

Worked for me. I clicked drive and then drove around.
Ah, there were no buttons for me anywhere on screen, so maybe it didn't fully load.

Thanks!

Couldn't bother waiting for this to load unfortunately
Cool, who is going to pay for it? This isn't rendering things on mobile.
Yikes the performance is terrible. You are not proving the point that you think you are
> with the service I've authored

You created Appmana?

> Cooking is hard.

> Just order out bro.

streaming != rendering
Can I open an OpenUSD file in a text editor and read it?
OpenUSD has a plaintext encoding mode, which by convention gets saved as .usda. The standard OpenUSD SDK contains two command line utilities `usdcat` and `usdedit` to do plaintext editing, but most programs using the SDK have better editing functionality by directly using the C/Python SDK.
The ASCII (plain-text, .usda file extension version) absolutely.

For large scenes/models, the normal .usd binary/compressed version is often used for efficiency reasons (and proper round-tripping of float values for xforms, etc), but you can convert between the two with the 'usdcat' util and the python/c++ apis for debugging.

> proper round-tripping of float values

Why do so many (all?) textual data serialization formats represent floats in base-10 scientific notation, anyway?

If we wanted floats that are 1. human-editable but 2. bijective with IEEE754, wouldn't floating-point hexadecimal (and "e" notation representing a base-2 exponent) be a better idea?

> human-editable

I mean, depends on the human. Most don't know hexadecimal, but know what 3.14 means.

The real issue is why do so many float parsers and printers fail to do exact round tripping? Designing a good algorithm for this was a bit difficult, but these days this is a solved problem.

If I had to take a slightly snide guess: because these are low level tools, so there's a 90% chance that these parsers/prints are written in C, or ultimately depend on C implementations. As any C programmer would know, C loves to throw "undefined behavior" at any problem it doesn't bother to document. Which is a lot.

That combined with almost zero package management for retrieving things that were solved decades ago means we keep coming into this issue, partially because of the mindset of C programmers.

This is just "hur dur C undefined lol" level of a comment.

If you are serious about your data format supporting round tripping you can and should specify the precise ASCII encoding of binary floats and the inverse. If that means implementations have to ship their own float formatter and parser than so be it - no one is tied to whatever comes with their libc, package manager or no package manager.

Some do (i.e. Nuke compositor .nk files in the VFX industry, which stores some float values as hex)...

but then you loose the human readability / "understand-ability at a glance" advantage, so it sort of depends what the use-case is...

The best of both worlds, at least in my opinion, would be to write a float as a polynomial in two parts (where either part alone is still a float): an integer part with an optional scientific-notation exponent; and a fractional part, where the fraction's denominator is always a power of two.

So 5e3 is a float; 3/8 is a float; and 5e3+3/8 is a float. Each cleanly and exactly representing particular IEEE754 values, while also being readable as a base-10 polynomials.

Maybe fractions of arithmetically-specified powers of two could also be allowed, for really big denominators. 3/2**26, for example.

That's not particularly user-friendly though: at least for CG/VFX software (where USD came from and is designed for), non-technical (at least in terms of understanding IEEE floats) people like artists often want to look at the values to verify stuff for 'debugging' (i.e. is the software tool I'm using actually exporting the correct values I selected in the UI params panel).

Having to do any form of interpretation (even scientific notation is not ideal in some cases), is not great for many users.

I love that a Nuke file can (usually) be passed around using no more than copy/pasted text.
FWIW, well-implemented round-to-nearest conversion routines (e.g. Python and IIRC Glibc, although MSVC is historically bad about this) will roundtrip IEEE>decimal>IEEE if you use the correct number of digits (at least 9 for singles and 17 for doubles), for reasons of mathematics and not implementation. (The other way around also works, barring exponent under- and overflow, but for at most 6 and 15 digits respectively, so I wouldn’t call bijective, strictly speaking.)

The conversions are not even that hard ... unless you want to deal with arbitrary (and arbitrarily long) decimal representations and not just those that arise from IEEE numbers. Essentially the only choice to make is whether the conversion to decimal will emit all the digits all the time (simpler) or the shortest number of digits that will round to the requested IEEE float when read back (less liable to be mocked in webcomics[1]).

Of course, using hex floats is much simpler than even the simplest implementation of the above; I just want to point out that IEEE floats are perfectly roundtrippable through decimal.

[1] https://www.smbc-comics.com/comic/2013-06-05

Is the plain text diff-able? Easy to resolve merge conflicts? I consider xml(collada?) not to be diff friendly.
Yeah, sounds kind of like the old Renderman RIB files. Does Renderman still use RIB files?

I've been so out of the loop it's insane. I learned not long ago they no longer use the original Renderman Shading Language.

Yes, absolutely.
I’ve been happy with what modelviewer.dev offers me; someone with very little experience with 3D on the web. It’s basically a wrapper for three.js to view glTF files quickly and easily. It lets me load very small files and interact with them with JavaScript.

It’s perfect for my needs as an educator and I know just enough to be able to show other educators how to create and deploy their own learning materials.