The format supports e.g. higher order curves and surfaces and apps like Maya or Rhino3D can read and write OBj files containing such data. [1]
Writing a parser for the polygon subset also comes with some caveats.
If your target is a GPU you probably need to care for robust triangulation of n-gons and making per-face-per-vertex data per-vertex on disconnected triangles.
Vice versa, if you are feeding data to an offline renderer you want to absolutely preserves such information.
I believe the tobj Rust crate is one of the few OBJ importers that handles all edge cases. [2] If you think it doesn't, let me know and I will fix that.
This is surprising for people familiar with one but not the other of the requirements of offline- or GPU rendering.
I.e. if you write an OBJ reader this can become a challenge; see e.g. an issue I opened here [3].
1. https://paulbourke.net/dataformats/obj/
This is a simple post-process step after parsing.
Good pipelines shouldn't rely on clever parser behaviour (as a general rule)
You may even want to consider adjacent topology for something as 'simple' as which of two possible solutions to take, when splitting a non-planar quad into two triangles.
Triangulation is simple only when your polygons are planar and convex and aspect ratios of resulting triangles do not matter under any 2ndary circumstances. Some uses e.g. require avoiding thin, splinter-like triangles.
In my own applications, it hasn't come up, as I've been mostly using primitives and dynamically-generated meshes, but am wondering if I should switch.
One caveat though:
> If the OBJ source cannot fit in memory, then the model won’t fit in memory.
I don't think that this is true: a (single precision) float textual representation is typically equal or larger than its binary representation (4 bytes), the floating point used in the renderer given later in the post. The numbers given in the cube example are unlikely to occur in real world examples, where one would probably expect more than 2 digits of decimal precision. That being said, for double precision floats, it might be true in many scenarios, but I would not make that a cardinal rule anyway.
This corner cut fits within the objective of the post, which, imho, isn't to make the most efficient program, but provide a great foundation in C to build upon.
https://stackoverflow.com/questions/7222164/mmap-an-entire-l...
Also obj material support is an absolute nightmare if you ever try and support that: there's technically a sort of original standard (made around 30 years ago, so understandably somewhat messy given how far materials and physically-based shading has come in the mean time), but different DCCs do vastly different things, especially for things like texture paths and things like specular/roughness...
(/a quick query) https://paulbourke.net/dataformats/obj/colour.html
https://github.com/tinyobjloader/tinyobjloader
It's fairly mature and handles many of the parsing footguns you'll inevitably run into trying to write your own OBJ parser.
I had a look at the code and it looked distinctly like C++, but it turns out there is a C version [1] too. Haven't looked into it further.
Nowadays you can have the same fun by rewriting the previous sentence using Vulkan instead of OpenGL, and glTF instead of OBJ.
You can see something similar in the MIDI specification. There's actual manufacturer codes and if you read through them you get a kind of 'who's who' of the synth era.
[0]: https://nullprogram.com/blog/2023/09/27/Also: https://aras-p.info/blog/2022/05/14/comparing-obj-parse-libr...
The function has quite questionable implementation. It fails miserably for strings with length < i.
Still, this function is called only once, and in that call, its i argument is always <= length, so it's perfectly fine (it's only UB if you actually pass it a bad argument).
This very mindset is a source of bugs and vulnerabilities. The author has high marks from me on safety and "make it hard to use wrong" and it's quite surprising to see such code.
The insanity would be assuming that every function is valid for the Cartesian product of all possible of its arguments.
What he probably needs is an assert
> The insanity would be assuming that every function is valid for the Cartesian product of all possible of its arguments.
Would it? That reminds me of a recent post on HN about proving the long (binary) division algorithm with Hoare's logic. It uses the "d > 0" precondition and proves that, indeed, the algorithm arrives at the required postcondition. However, the algorithm still terminates and produces something even when d == 0. What does it computes in this case? Is it useful? Should such questions even be considered?
Yes, a better understanding of the problem gives you a better understanding of the preconditions. Always ask if you have that right and weaken accordingly.
In general you can write better code when you can make assumptions.
Code to handle every possibility is filled with error prone branching, that reduplicates effort at every function.
This isn't some 100k line long program where this function is used all over the place and code churns constantly so checking invariants in the function definition makes sense.
It is called in one (1) place in a small program.
It could use `str*` functions without any issues then. Nul-terminated strings are perfectly safe with assumptions to follow.
Anecdote: I fixed 3 reported segfaults and another 2 after fuzz-testing in a small 500 line lib. Original author had the same cowboy mindset about keeping all stuff in his head. It's always last words before getting into CVE database.
Nobody is saying that. Name, document, and assert.
Good code consists of easy to use abstractions. In general Chris's blog is dedicated to poking bad abstractions and giving good examples. `substring` is objectively bad.
You (and other commentators) literally arguing that keeping staff in the head or making some documentation or notes or forcing yourself or others check low level implementation details are better than making one trivial fix and forget about it. I find it really amusing.
Good code consists of solving a problem simply and efficiently. You can have a great program which is concrete. Abstraction is a tool for managing complexity, not a goal.
I would really encourage writing a large program C or assembly, as a practice of how to deal with programming problems without immediately wrapping things in an interface. A lot of things that feel like producitivity end up being wastes of time.
While it is "obvious" that it is correct, it is, in fact, neither obvious nor correct if A. you ever subtract from then len field, and B. you use "len != 0" as a check for "is string non-empty". This program does both things quite a lot and it requires a conscious check to re-assure yourself that no, in this particular program, the patterns of acitons A (subtractions from the len field) never break the property B (non-zero len means that the string is not empty). But any minor modification may accidentally break this harmony if you are not aware that it is required to hold.
My question is: Does the author actually use Windows XP?
I've switched to XP (from Windows 7, on a VM) and the performance is astounding even on limited hardware settings. No bloatware, just good old Win32 x86.
It's sad how bloated things have gotten.
You wouldn't believe how much traffic is hammering IP ranges with known vulnerabilities. Forward port 22 to your Linux box or similar, check the logs for number of "connection attempts", it's going to be glorious log. A-HOLES of this planet are doing this just to get control of devices connected to the internet, if for no other reason than use them in DDoS-for-hire service. If there is a quick buck to be made.. they'll be all over it. Human parasites.
The main threat would be connecting to a malicious server that attacks some hypothetical hole in the TCP/TLS stack when you connect, but such servers aren't really omnipresent, and you can apply the usual measures of 'making regular backups' and 'not keeping extraordinarily sensitive data on a VM' to mitigate any impacts.
(Looking at actual historical holes, I find things like CVE-2005-0048, which requirs a malformed IP packet a modern router wouldn't pass through, and CVE-2007-0069 and CVE-2019-0708, which require a malicious incoming connection to a particular port. There's also stuff like https://www.forcepoint.com/sites/default/files/resources/fil..., but that's not really specific to XP services, and requires many stars to align unless you're running a vulnerable HTTP service.)
Significant overlap between the types of people who use WinXP and write 3D file format importers in C, I think! Though I prefer 7 myself.
The bit about OBJ parsing is neat, though.
Good Rust code will also care about memory allocations to the same degree as the C code, the difference is that Rust will help you out in making sure your thinking is correct. My experience is that good systems programming has thinking about memory allocations not as an annoying side issue, but as a main concern.
If you want to talk about performance, you better come armed with numbers. If you don't, you're not writing "high performance" code.
For stuff that you run only for yourself and _always_ executes in a blink of an eye I do agree.
> By robust I mean no undefined behavior for any input, valid or invalid; no out of bounds accesses, no signed overflows. Input is otherwise not validated. Invalid input may load as valid by chance, which will render as either garbage or nothing.
Robust is a baseline for high performance programming.