Cieric

Interesting, thanks for the info.

I'm (hopefully) getting a G1X soon, so I think I'm going to put it to work printing this stuff out. I'm now excited for this as a use case and I kind of hope someone builds something to convert an existing factorio world into a 3d model, though it might be to big to actually print so maybe a way to take a section would be even better.

Yeah, that sounds like the system I rediscovered. The only other thing I'm adding to try and lean more into that system are assertions(?) that are in the middle of a function, that can basically break it up into blocks on their own where the first block proves it true and the second block assumes it's true. So effectively the same thing as breaking it into 2 smaller functions. My main thing right now is, I'm fairly certain there is something wrong with my compiler, I'm a basically a novice in contracts, I'm intermediate in compilers, I'm a novice on SMT proofs, and I wrote the whole thing at this point using AI just to test an idea. So I'm just trying to throw everything I can at it to try and break it. I need to start building it again from scratch (without AI) so I can truly understand where it might break and what doesn't work.

Ah damn, okay. Long functions with a lot of sub calls is a known problem. I've been able to work around some of the issues tried to them by making every function an independent "compile unit." and then solving them each individually in the SMT solver. My experience in contract based programming is still relatively light, I won't lie there. The most I've had to do with contracts was ada, and even then it wasn't much. Everything else has been self enforced in languages without explicit support (and hence no compile time checking.)

You sounds like you have more experience than me in this space (specifically contracts). I'm curious if you have any examples right off hand that would need whole program analysis. I need more examples to throw at my toy language that's not just another lock free work stealing queue.

Yeah, I heard spark was used on a small component in the nvidia gpu firmware so others seemingly agree. I'm mainly in the user mode driver space so my ideas have been around having a kernel mode driver that (assuming a correctly functioning pc) can't crash and user mode drivers that can't be exploited (at least in the rop chain sense). I'm kind of picking ideas from other languages that I like zig's error handling, ada's contracts, rust's lifetimes (hopefully soon to be replaced with more contracts instead), and things like how you can use "gas" in lean to prove a loops will terminate. I'm mainly building it up with AI right now for experimentation, but I also can't really trust it to be correct either because of using AI. Once I settle on the syntax more and pump out a lot more tests, I'm probably going to rewrite the compiler by hand (hopefully in the custom language itself.)

There is a small hint of it at the end, but I really hope compile time contract assertions become more common. I know some languages like spark, dafny and a few others do it and generate implicit contracts for things like divide by 0. I've been experimenting with my own custom language that do these things and going back to c++ every day at work is actually a slight let down because of it.

Another thing that it could be is quick charge, since that seems to conflict with some PD chargers as they'll try to negotiate, fail and then reset. My Light L16 camera has this problem so I have to use the charger it came with or find something dumb enough that it doesn't try anything special.

It's been a while since I've tried to run it, but it's a mix of Nvidia and AMD GPUs and only AMD CPUs (everything portable is all AMD though and that's where my gripes are.) I'm sure the opencl backend has gotten better over time, but it always seems to drag behind the cuda backend. At this point I wish we could just have a vulkan backend and be done with it.

Thanks for bringing that up though, after a quick search that I guess I haven't done in a long time, it appears that colmap does now have a hip backend. So I guess that's going to be my weekend now.

I'm sorry, but the article doesn't cover anything about the preprocessing steps that are required for 90% of gaussian splat implementations. That preprocessing step is almost always colmap which takes pictures or videos and uses SfM to figure out the camera parameters and their position in the 3d scene, it then does basic point reconstruction and dense point reconstruction. That info is what gaussian splats take in, it converts the points from a colmap project into gaussians and then optimizes them through differentiable rendering using backprop to optimize the gaussians to better match the images at the calculated positions of the camera from colmap. Looking over the project files also shows that they consume colmap projects, my question wasn't about the gaussian splat implementation, it was about the defacto standard colmap preprocessing step that is also required.

Thanks, I've been exploring a lot of the papers and seeing what I can get working. Some of it really has been interesting, but I just never seem to be able to get it to work well. I might just need to throw myself at it all a bit more. Thanks for the links though, I'll check them out.

I'm still very fascinated by gaussian splatting, but the issue I always run into is the need to use colmap to generate the camera positions and get the initial point cloud. Which colmap effectively still needs Nvidia for dense point clouds last I checked. I'm curious though does anyone have anything else they've tried that worked well? I've tried a few different things (most of the time getting stuck on just compiling the thing) so I'm curious if anyone has any suggestions that I should focus more heavily on getting working. I have some poor quality videos I'd like to try and use and I'm willing to put in some manual work, but it feels like it's all automatic or nothing. Thanks for any suggestions that any of you have.

Oh yeah, I do think it's the shielding. I was just kind of surprised by it since I've never bought a cable that's done that.