thelazyone

Aside from the refreshing fact of this not being yet-another-perlin-noise video, the author makes some good point about feasibility of corrosion algorithms and how those can be heavy and don't work well on a "just in time" generated map.

The second solution in particular is fascinating, although it doesn't offer a good solution to generate a seamless heightmap in the current state. I guess that combining that with some Perlin noise to determine which areas get to have starting seed points for the ridges would work?

Thoughts?

Special mention to the remarkable work of graphics and rendering that is behind the video. Some of those 1-second transitions imply a considerable amount of custom code, from the corrosion examples to the various overlaying heightmaps.

I'm very much torn between Plasticity and MoI for my next sculpting project. I've always used Blender but for some stuff I'm finding myself in need of some proper NURBS tool. I've spent a few hours on Plasticity, I'll do the same with MOI and see how it goes! :)

Currently the only thing that is stopping me from an insta-buy is that the export quality seems to be pretty low poly, even when the detail slider is all the way to 1.

Of course my trial version is nowhere near there, but watching several videos it appears that even the highest settings still are far from a proper high-poly export.

Since I work with 3D prints, that is a blocking issue for me, BUT the videos are all several months old.

Anyone with a more recent experience with Plasticity has something fresher information about that?

This is a good question - not only for the actual ethics of the training, but for the future of AI use for art. It's both gonna damage the livelyhood of many artists (me included, probably) but also make it accessibly to many more people. As long as the training dataset is ethical, I think fighting it is hard and pointless.

"Using open source code is a skill: knowing how to navigate repos and someone else’s code, understanding how to troubleshoot and navigate communities to get help, discerning between quality projects and junk… this experience is a hard-won component of being a modern software explorer. It can take you further than you might realize, past mere bits and into the land of electrons and atoms."

Very wise words. Coming from sw/hw industries I probably could work around heat pump microcontrollers without too much hassle and I well know the pain of physical components messing up your debug process. But such industries rarely rely on open source, and all the OSS I used was for personal projects. That is definitely a big limit for my future work opportunities! :/

I wonder what kind of interesting applications could be done on e-ink harnessing the advantages of the long battery life and not suffering by the slow refresh rate. Sure, porting doom or implementing a terminal is an interesting and probably challenging feat, but still it's applications that don't shine on an e-ink device.

Maybe some "slow" strategy game, that updates upon certain events but might remain unmodified for hours at a time? Or - more in general - an application that is required to be on for a long time but really doesnt' change often.

I think that the initial question was "why a 0 resistance compared to a ridicously low resistance". And my point is that it's easier to get a superconductor than some material with "ridicously low" resistance. As you said, silver is unusable for potent magnets, and such is any other non-superconducting magnets.

Probably if we had materials with a billionth of the resistance of silver they would work, but we haven't. And we have superconductors, luckly. :)

I think it's a fair question. I guess the answer is "because we have superconductors, and no material with 'very small resistance' instead".

Also note that while there is zero resistance you still have parasitic currents and general interaction with the rest of the environment. So no perpetual motion for us today!

Sounds like a logical step forward from current debuggers! I had some colleagues who bragged of not needing debuggers for their workflow... Well, sometimes I really do.

Yeah, the other replies were pretty convincing about that point.

That's a fair point, well made. In that case --- yeah, we just have to wait and hope for better solutions/materials for our screens!

There's a big difference between having a solution and point out that there is no theoretical hard trade-off. ^^"