Pipes and named FIFOs are easy and great. I say this after implementing various IPC methods (unix domain sockets with fd passing, POSIX message queues, 0MQ, XML RPC, local TCP sockets, just to name a few). Use a simple line oriented protocol. If you are passing complex data through your IPC, you know it's time for files. Shared memory is another way to do IPC but hopefully you have robust method of detecting the liveliness of your local processes and you want to give up the Unix file paradigm.
Apparently you didn't bother to fully read their comment, or even look at the page. It is a subtracted sphere, meaning it could be any shape contained within a sphere, and the one in question has features that give axes, and to me eye appears to have a strange axial rotation
As a matter of fact I even put my finger up to the screen to verify that the edges were not in any way wobbling. The subtracted shape is a gyroid, which in no way has natural axes, so I beg your forgiveness for still not understanding the question.
I think you are referring to first video on home page while other two are talking about first video on examples page. That example has CSG operations on solids that share the vertical axis so the resulting shape should not wobble.
Yes, wrong side of the bed, I usually sleep on the left, but I definitely was on the right side that day, not that it's pertinent.
I meant what I said, that it appeared that you hadn't bothered to read the page, or to fully read the comment. Your question is talking about a sphere (which can, btw, be rotated "off axis"), while the original comment was indicating one of the subtracted spheres from the page. Any of those subtracted spheres could be rotated off axis. So either you were ignoring a pertinent part of the original comment, or hadn't bothered to look at the subjects that comment was directed towards (either of these scenarios would violate HN guidelines).
Off-axis rotation could mean many things in the context of the original comment, as is pointed out by other responses to your first comment. While it's true that a gyroid has no planar natural axes (by design), a gyroid can have many natural axes, depending on the space it is modelled in and the criteria for axis selection. For example, an axis can be found in the radial symmetry about the center of mass of a gyroid, in an infinite number of planes.
A sphere can also be rotated off axis. If the axis of rotation is not projected across the center of mass of the sphere (rotation would be different than the infinite number of natural axes going through center of mass) is one way. Another way would be if the axis of rotation tended toward one of the COM natural axes at both ends, but was non-linear. Another off axis rotation would be if the axis of rotation was the natural axis, but was not co-planar with the rotation of the viewing axis, which would make it appear to wobble.
>Apparently you didn't bother to fully read their comment, or even look at the page.
Was there a need for this attitude (which, by the way, violates HN guidelines)?
I was looking, not unreasonably, at the linked page. I see that indeed the first example on the "Examples" page exhibits this wobble - thanks to user jmiskovic who was actually helpful.
I'll direct you to my second response to you, where I point out why it appeared from what you wrote that you either hadn't read the original comment fully, or had not examined the subject of that comment. I believe pointing this out was not a violation of HN guidelines, while your negative attitude in multiple comments since then is most definitely in violation.
As far as being helpful, I don't think your first comment falls into that category either.
I'd argue that an invalid string concept would be neither correct nor efficient. Why should all code that deals with strings carry the burden of fallibility of a subset of string functions?
You've mentioned NaN propagation in another comment and I think that's a perfect example of the problem with this approach. Sorting a vector of arbitrary floats is a notoriously thorny problem because any float could be NaN, and as NaN is incomparable to any other float, there is no total ordering of floats. There is no general solution to this problem that doesn't involve making assumptions that could be faulty for some applications.
Please support your argument against correctness by providing an example where an INVALID string as input to a suitable modified generic string function would result in a valid string.
I would expect an invalid string to have an invalid length. For integer-valued lengths you'd have to use a negative number to differentiate from a valid, empty string. But then the sum of the invalid-string lengths differs from the length of the concatenated invalid strings. Which is wonky.
Safe string manipulation never exceeds the bounds of the buffer. So negative values are dangerous, as all as any additions that would exceed the maximum size.
Negative lengths are not compatible with unsigned representation.
A system implementing invalid string values must choose a text encoding such as UTF-8 that supports the concept of an invalid character. Null termination is too flexible. As such is simple length prepending.
I don't understand the fallibility.
Clearly misuse of string functions is epidemic.
A propagating INVALID string result makes it very clear there is a logic error and not an exploit.
I understand how one could shoot down implementations, but none has made a convincing argument about shooting down the idea.
I wouldn't prefer one more special case to test against (empty string / null string / 'invalid' string). Why can't those operations just return error codes instead? How about memcpy if you try to memcpy into a buffer that's too small - it writes an 'invalid buffer' type instead?
”This would be the result of trying to copy a string to a buffer that is too small.”
C doesn’t have the notion of “size of buffer” (yes, arrays have a size that can be queried by sizeof, but only at compile time). You would have to fix that, first.
NULL is the lack of any string.
If one view a string as a result of an operation, then an INVALID string is the consequence of bad input to an operation.
If you have studied Computer Science, you should know that the null string is quite a valid string.
Let's take strstr, which finds a matching substring needle in a haystack string.
-returns a NULL string if the needle is not in the haystack.
-returns pointer to first matching substring.
Extend strstr with VALIDITY
Understood behaviour if both are valid.
Say the haystack is INVALID...as the return value is NULL or a strict substring of haystack, should return INVALID. A poison haystack should poison dependent strings.
Say the haystack is valid but the needle is INVALID...should return NULL. A valid string never contains an INVALID string as a subsequence.
I tried really hard to find a main() function browsing the demo source code, but I could not. I also find it interesting that code boilerplating is called out as a problem, but I run into code like this:
Choose the size representation that bests fits your use case:
// Put this in header to help user calculate allocation needs but hide size from user
size_t LIBNAME_alloc_size(param1, param2, ...);
// Put this in the header to hide the size from user code but allow inlined size calculations
extern const size_t LIBNAME_ALLOC_X;
// Put this in the header to make size known to user (for static const allocation)
#define LIBNAME_ALLOC_Y ((size_t)42)
That's pretty excellent. For those who don't watch the videos, they feature a feeding device that must be spun to release food. Video 2 features the pig figuring out that spinning the wheel releases food, and by the last video, the pig is spinning the wheel numerous times to release several food drops before eating.
Sell me: I am a crusty old C++ programmer who started numerical and geometric programming on an SGI machine at the turn of the century. I have seen many academic and commercial 3D libraries come, go or perform poorly (vcollide, RAPID, CGAL and many proprietary ones).
It looks interesting but what makes this library any better than what's come before? Why should I learn Rust to use it or really for any computational geometry problem?
I'm not sure. I certainly would never use a third party collision library because I think collisions are simple enough, but on the larger subject of whether Rust is suitable for game programming; I think so, but cannot confirm. There are a lot of abstractions that require pointer dereference, which is somewhat likely to give you a performance drain, and those abstractions are I guess somewhat harder to avoid than in C++, but not terribly so. Both languages give you the ability to do "data directed design" if you really really want to.
My preference for Rust stems from my preference for interfaces, or traits as they are called in Rust. If you want to use features like these then Rust is a no brainer. I have yet to see the true impact on performance these abstractions have however.
What abstractions are you referring to? If you're using traits and writing your functions with generics there shouldn't be any overhead, other than the increased number of instructions, but this is no different than C++ generics. There are trait objects, but these come up somewhat less often then you would think, and have the same performance as using abstract classes/polymorphism in C++. But maybe you're referring to something else?
I am referring to trait objects, and I use those pretty extensively (although I limit my usage because I am making games and want to avoid a pointer dereference). For libraries you might not need them as much, but I definitely find their convenience indespensible for application side programming.
Personally, I've found that most cases you can avoid using trait objects by just using generics, but it obviously depends on your use case. You especially need trait objects to have things like heterogeneous arrays. Trait objects are pretty much the same as C++ classes with virtual methods, with one tweak in the representation. A C++ object is referred to by a pointer to (vtable_ptr, class_fields). A trait object "&Foo" is a fat pointer (vtable_ptr, ptr_to_fields). So a trait object reference is two pointers, but doesn't have a pointer stuck to the front of all of its structs. Method invocation requires you to dereference the vtable, get the function pointer, and call that, passing the data pointer. In C++ you would dereference your pointer, dereference the vtable, then pass the pointer to the function. If anything, I think the Rust method may be faster because you avoid the double de-reference, but it's probably so small as to be unmeasurable in all but pathological uses.
Is this strictly for building shippable software or any time you need collision?
Maybe I am just a web programmer who is really bad at math and programming but this seems like a crazy thing to rewrite for many projects. Even if it only takes a day or an afternoon that is time you could have spent proving if your idea works.
> I certainly would never use a third party collision library because I think collisions are simple enough
Ehhh, I haven't seen a really good, super robust solution for mesh vs. mesh. Deciding whether two meshes collide is simple enough, but robustly pulling out associated information like overlap volumes, penetration depths, etc gets pretty hairy pretty quickly - you start running into similar problems to mesh booleans.
The reason why is that mesh vs mesh essentially should never be used in video games. The accuracy in hitbox bounds and ease of use (making a model mesh your collision mesh) you get from mesh collisions are completely and utterly overshadowed by the performance and lack of accuracy in determining the time of impact.
At 60 fps it's really hard to tell the difference in collision between a typical dodecahedron and a sphere. Just use a sphere! (Or, more likely, some aggregate of AABBs, spheres and capsules)
Oh yea, for a game I would almost certainly decompose into some sort of union of easily handled convex shapes. There are definitely applications -- robotics, engineering, hell, even film -- where more accurate mesh-mesh is needed, however, and most solutions are super domain specific and ad hoc.
> The reason why is that mesh vs mesh essentially should never be used in video games
Or, alternatively, the reason why mesh vs mesh is never used in video games is that it hasn't been solved well yet and we have to stick to simplified collision geometry and the resulting glitches we get in games?
Mesh vs mesh collisions will never be faster than primitive collisions. Also, simplified collision geometries do not produce glitches in the same way mesh vs mesh collisions do. At most you may have a collision between two primitives where the models don't actually seem to be touching. But this can easily be circumvented.
In fact, I would argue that a lot of the physics glitches we've seen are probably the result of using mesh colliders when a simplified geometry would have sufficed.
Ever used OpenSCAD? Try doing CSG operations with CGAL on complex STL surfaces. Then take those same surfaces with vtk, use their boolean operations. Faster but with significantly more errors.
