Live data from Hacker News

Why I rewrote the mesh generator of Dust3D from Rust to C++

blogs.dust3d.org

61–70 of 283 posts

Re: Why I rewrote the mesh generator of Dust3D from Rust to C++

#61
post #12

Doing game dev and digital content creation in anything but C++ and some python is simply a fool's errand. Any decent software in this area needs to use libraries written in C++ to have even a remote chance of being successful. These libraries are often written in ways that makes wrapping them for other languages impossible or at least force the exclusion of some desirable features in the bindings. In other words, C+…

The first non Unity non Unreal game I thought of, Celeste, uses C# and XNA. Lots of games use other languages these days.

Re: Why I rewrote the mesh generator of Dust3D from Rust to C++

#62
post #58
post #54

Earlier quoted context omitted.

I never met a GC that can deal with millions of allocations per second while having several millions of objects in the young generations. Some mesh processing algorithms have a tendency to get you there very quickly if you do not employ custom allocators. At this point you already defeated the GC provided by the language.

You would have to be dealing with a very large number of meshes at once, if you were churning through millions of vertex and uv arrays per second. I can't say what you should use in this scneario. But this is a pretty niche scenario! And you would probably want to focus on parallelism, where C++ again is not the best.

No, I am talking about operations that alter the topology of single large meshes. Just creating a single tesselated sphere with full topological information gets you there easily.

Re: Why I rewrote the mesh generator of Dust3D from Rust to C++

#63
post #26

Earlier quoted context omitted.

Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.

Need is relative. If you can get the extra speed, why waste it? Life’s too short to spend it waiting for your computer. And in this case, the author does need cpp speed.

I think the article didn't say anything about performance requirements.

The app is Dust3D, a ease-of-use focused mesh editor which deals with simple meshes.

Certainly from the blog post you get the impression that programmer productivity is a consideration in his choice of language.

Re: Why I rewrote the mesh generator of Dust3D from Rust to C++

#64
post #56
post #48

Earlier quoted context omitted.

And it is a special snowflake because of that. Unity needs to pour a ton of resources into this to make it viable and competitive. IL2CPP and the Burst compiler are proof. A company with fewer resources would have to give up on this approach.

Mono runs fine. IL2CPP is more of a work around to get AOT on iOS and Burst is just a nice linter but you could write the same tight loops now and mostly likely get very close. Plus, Burst isn't even out so its odd to bring it up as necessary.

Unity makes it very clear in their blog posts that Burst is a special vectorizing compiler. It is not a linter at all. I am not sure where you got that notion.

IL2CPP was required to be able to stick with C# and stay relevant for mobile gaming. They forced themselves into this corner by wanting to stay with C# and become relevant for mobile gaming.

Compare all this to Unreal. By sticking to C++, they do not have to commit the same amount of resources to programming language related tooling.

Re: Why I rewrote the mesh generator of Dust3D from Rust to C++

#65
post #62
post #58

Earlier quoted context omitted.

You would have to be dealing with a very large number of meshes at once, if you were churning through millions of vertex and uv arrays per second. I can't say what you should use in this scneario. But this is a pretty niche scenario! And you would probably want to focus on parallelism, where C++ again is not the best.

No, I am talking about operations that alter the topology of single large meshes. Just creating a single tesselated sphere with full topological information gets you there easily.

Ah, we may be talking past each other then. So I reiterate my point from upthread:

> Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC.

Re: Why I rewrote the mesh generator of Dust3D from Rust to C++

#66
post #61
post #12

Doing game dev and digital content creation in anything but C++ and some python is simply a fool's errand. Any decent software in this area needs to use libraries written in C++ to have even a remote chance of being successful. These libraries are often written in ways that makes wrapping them for other languages impossible or at least force the exclusion of some desirable features in the bindings. In other words, C+…

The first non Unity non Unreal game I thought of, Celeste, uses C# and XNA. Lots of games use other languages these days.

XNA is dead. Microsoft officially recommends MonoGame instead.

When a game seems to be written exclusively in a high level language like C# then there is almost always a massive framework underneath that integrates a lot of shiny C and C++ libraries for the real heavy lifting.

Re: Why I rewrote the mesh generator of Dust3D from Rust to C++

#67
One thing that I don't see pointed out is that Rust is a nightmare if you are dependent upon mutable algorithms.

I suspect that mesh generation is very much a mutable algorithm domain and probably a high impedance mismatch with Rust.

For example, simple things like mapping a struct of three elements to a vector of three elements were, at one point, very difficult if not impossible in Rust.

Re: Why I rewrote the mesh generator of Dust3D from Rust to C++

#68

Earlier quoted context omitted.

> capacity to change Good luck making changes to a 100kloc Python codebase.

If you have good manners, Python codebases can easily grow over 100kloc mark. Static type annotations, using descriptive variable and class names, type checks on user input(esp. libraries) makes growth safe and simple.

That’s a good observation, thing is, Rust just makes the manners mandatory.

Re: Why I rewrote the mesh generator of Dust3D from Rust to C++

#69
post #65
post #62

Earlier quoted context omitted.

No, I am talking about operations that alter the topology of single large meshes. Just creating a single tesselated sphere with full topological information gets you there easily.

Ah, we may be talking past each other then. So I reiterate my point from upthread: > Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC.

Thia is true only if you have the foresight to write custom allocators. Unless you limit possible mesh topologies, you must deal with many tiny arrays for each vertex, edge and face and their lengths are not uniform.

Re: Why I rewrote the mesh generator of Dust3D from Rust to C++

#70

I wonder how many of the Rust defenders in this article actually know C++ and have written a production used Rust system, instead of a side-project on github, so that they can compare in an informed way? The author certainly has, but who else has? Step forth priests of Rust! As for me: I use C++ at my job daily but have never done Rust so I cannot compare. What I do know about is "memory safety" in C++, and to be hon…

Rust memory management is just RAII, and there are no exceptions, just nice Result types and syntax that makes returning them and handling error cases simple and pleasant.

If you want to handle closing a socket, it’s as easy as implementing the Drop trait on your type. Without an unsafe block there’s no way your destructor won’t be called.

struct Socket(u16);

impl Drop for Socket {...}

To answer your question there’s no special casing around memory vs non-memory resources. Your socket is backed by a kernel ID which must exist in memory, of course, so by adding a Drop implementation you can then define the special treatment yourself. If threading considerations exist you can explore the Sync and Send marker traits too.

It’s largely a much simpler language than C++, you just have to learn how to write it. A lot of the friction/confusion IMO is that it looks so similar to languages you use at first glance you just start writing the code you used to in a Rust-y way, instead of Rust, then are frustrated as to why it won’t build.

In some ways it’d be clearer if it looked “foreign” like prolog — it’d be a lot less popular though haha.

Post reply on HN