Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blogs.dust3d.org

Post reply on HN
Print view View original

71–80 of 283 posts

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

#71

Post by pjmlp »

gmueckl wrote: post #48
est31 wrote: post #27

Earlier quoted context omitted.

Unity, one of the most popular engines out there, is mainly about C# for the gamedevs.

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.

The same was said about the game developers using Pascal and C instead of Assembly, followed by game developers using C++ instead of C.

The industry always needs some pioniers willing to do the investment regardless of the naysayers.

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

#72

Post by pjmlp »

gmueckl wrote: post #66
jayd16 wrote: post #61

Earlier quoted context omitted.

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.

Time travel 20 years back on some USENET forum.

"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 Assembly libraries for the real heavy lifting."

Time travel 30 years back on some BBS forum.

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

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

#73

Post by gmueckl »

fulafel wrote: post #63
adamnemecek wrote: post #30

Earlier quoted context omitted.

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.

3d modelling is a problem domain where performance is the most important feature. Without sufficient performance, the tool.is not interactive. And direct interaction with immediate visual feedback is the whole point of these programs.

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

#74

Post by pjmlp »

fxfan wrote: post #28
Vogtinator wrote: post #14

Rust is still completely unusable as you can't use dynamic linking as there's no stable ABI.

"completely unusable" You forgot to tell Microsoft (biggest software seller on earth)and they decided to use it in actix

And are proposing it alongside C# and Core Guidelines compliant C++ for new systems software.

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

#75

Post by fulafel »

gmueckl wrote: post #69
fulafel wrote: post #65

Earlier quoted context omitted.

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.

Yes, depending on what you mean by custom allocator... but this is the same in C++ too, right?

To store custom vertex / face attributes, you can use a variety of sparse techniques to save memory from sitting unused in attribute arrays. Basically you want an interface of get_attribute(type, vertex_id). This sparse matrix, trie, or whatever can be backed by int or float array storage instead of many many tiny malloc'd/gc'd objets.

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

#76

Post by mjburgess »

TomVDB wrote: post #35
mjburgess wrote: post #22

Earlier quoted context omitted.

Static checking burdens the developer with thinking more, etc. -- for sure. The cost is requiring a developer with stronger cognitive abstracting skills. Those people tend to be academics (its almost a definition of a good academic) and also, perhaps, less pragmatic. The ease of programming is not merely a matter of knowledge or experience, base cognitive skills play a very significant part which are largely an at-bi…

> In otherwords: the unable are often snobs. Oh the irony.

You'll find no value judgement in my comment.

There are many axes of intelligence, as well as of human value in general. I only said that comfort-with-abstraction is one axis on which people vary -- and I'd say that's exactly what the previous comment relies upon.

All it says is "this is needlessly hard", the only reply can really be: yes, for you.

I was offering an explanation of why that is; or else are we really saying that this "hardness" is universal?

One of the more important characteristics of a developer is pragmatism which has zero covariance with comfort-with-abstraction. And so, why not value those who have that more?

That is, to be better at abstraction isnt to be a better developer. It is only to be better at one sort of development. Equally, to have more pragmatism is to be better at a different sort.

There's no snobbishness in my comment, only in a person who reads into it a value judgement about this specific form of intelligence.

Why read that into it?

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

#77

Post by fulafel »

gmueckl wrote: post #73
fulafel wrote: post #63

Earlier quoted context omitted.

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.

3d modelling is a problem domain where performance is the most important feature. Without sufficient performance, the tool.is not interactive. And direct interaction with immediate visual feedback is the whole point of these programs.

Having worked in 3D, including tools, it's my experience that features and productivity (=program is delivered on time) are the most important features :)

The code needs to be "fast enough"¹. Though this often means more attention to speed than in other kinds of software. To rephrase, speed is often necessary but not sufficient to make good tools.

¹ I try to avoid using "execution speed" and "performance" interchangeably, since a crashing, late or incorrect fast program is not a well performing program!

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

#78

Post by gmueckl »

pjmlp wrote: post #72
gmueckl wrote: post #66

Earlier quoted context omitted.

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.

Time travel 20 years back on some USENET forum. "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 Assembly libraries for the real heavy lifting." Time travel 30 years back on some BBS forum. "When a game seems to be written exclusively in a high level language like C or Pascal then there is alm…

Except that games back then were limited in code size by what could be stored in memory on the target systems. All the game code that I have seen from the 80s and early 90s came in well under 100kloc and library dependencies weren't a thing because of the same resource constraints. This changed over time and now almost any contemporary and technically decent game sits on top of several hundreds of thousands or millions of lines of 3rd party code.

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

#79

Post by coldtea »

geezerjay wrote: post #34
Barrin92 wrote: post #6

The first few comments here seem to argue against the article, as do comments below the post but I am very much with the author. I strongly disagree with the Rust mentality, and the general mentality of statically typed languages with extremely prohibitive compile time checks, that seem to become more common. Underlying that model seems to be a concept of software like a sort of renaissance master's marble statue, er…

> The downside that the author points out seem to be often neglected. Constant interruption and battling with the type system during development, when mental overhead is a problem. This assertion is just wrong. The author makes it quite clear that he doesn't know the language and is still taking his first steps ( "I am still a Rust learner, not a veteran" ), he implies that has problems with correct memory management…

>However, the author is still someone who does not know how to use a programming language and is still bound to not only the mental model of another programming language but also bad practices that lead to problems.

Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code.

Now it's applied to the other side (Rust is fine, you're just not good enough in it yet to use it properly, that's why you're discouraged).

Well, sometimes the language is not fine, and its ergonomics can be all wrong.

In C it was the type looseness, bad standard library, and presence of many foot guns.

In Rust it's the overt explicitness of the borrow checker, and the friction it adds to one's programming.

I don't care if the author is a Rust expert or total newb. Someone who can write a 3D modeler in C++ is someone who should be able to use any new Algol-derived language with ease in short time, regardless if they hasn't seen a line of code in that language before.

If they can't, something's wrong with your language's ergonomics.

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

#80

Post by gmueckl »

fulafel wrote: post #77
gmueckl wrote: post #73

Earlier quoted context omitted.

3d modelling is a problem domain where performance is the most important feature. Without sufficient performance, the tool.is not interactive. And direct interaction with immediate visual feedback is the whole point of these programs.

Having worked in 3D, including tools, it's my experience that features and productivity (=program is delivered on time) are the most important features :) The code needs to be "fast enough"¹. Though this often means more attention to speed than in other kinds of software. To rephrase, speed is often necessary but not sufficient to make good tools. ¹ I try to avoid using "execution speed" and "performance" interchange…

Fair point. Let me rephrase my point of view a little: you haven't made the users truely productive unless the tools are able to provide responsive and accurate interactive feedback. Anything that causes feedback to be non-immediate makes it harder for the user to dial in the exact results they want. They have to spend more time and give up when they have reached an inferior result that meets basic quality standards. Smooth and direct interaction makes them go the extra mile while enjoying the process.
Post reply on HN