For Tarot, did you generate base-color, roughness and normal maps? How do you make sure something like the roughness map doesn't deviate slightly from the base-color?
But basically diffui's build step provides an API to create normal/roughness/depth maps from images. It's essentially an interface to fal.ai's Patina model, which does a really good job at creating those.
The one thing that's missing with it though is metalness maps (Patina can theoretically output them, but they only have a ~10% success rate I've found). I'm trying to train my own diffusion model now to help generate those so the reflectivity isn't fully uniform. I just posted very, VERY early results here - right now my model has around a ~25% succes rate: https://x.com/pwnies/status/2082980850120163756
I'm a full stack Rails and React dev with 11-years of experience. Product focused, from wireframing and user stories I've helped companies through greenfield app development, rearchitecting existing apps, and maintaining legacy products.
In my free time I like making 3D-experiences and mapping GIS data.
I'm a full stack Rails and React dev with 11-years of experience. Product focused, from wireframing and user stories I've helped companies through greenfield app development, rearchitecting existing apps, and maintaining legacy products.
In my free time I like making 3D-experiences and mapping GIS data.
I hadn't seen this before, thought it looks interesting. Wondered why it is perpetually unfinished... until I saw the 'Make an off-line version of this book' and 'Make a PDF of the book' sections.
Oh, OK. The authors have chronic obsessive abstraction syndrome, aka Endpoint Avoidance. What a shame.
Anyone have links to an actual PDF of it? Or a zip of the entire 'book' fileset?
I think if Rails had focused on giving real first party support to interoperability with whatever frontend framework you brought to the table it would be so much bigger right now. They put a lot of work into Hotwire but I just want to use React, and I'm sure others want to use what they're familiar with.
I've built api only. It would be sick if it were easier to sprinkle react/vue/svelte/whatever in your haml views if you only needed a little bit of interaction but didn't want to spin up a whole other frontend.
I’m hardly an expert with Rails, and I integrated React twice, on two very different sites, using API controllers. The nice thing about React is that you can limit it to an island on the page, and don’t need to buy into the router, etc. that said, I did disable Hotwire to make my life easier.
Yeah but I wish in an alternate reality DHH chose a different route. If you go API only then you lose half of what makes rails great. It would be sick if you could render React/Vue/Svelte easily in your haml views and not have to have a js repo then figure out jwts and auth.
Dunno I loved rails, built monoliths, built api only, but when I tried sprinkling a bit of react in my views (say you only need a little bit of interaction, or want to use a react date picker) then theres all these sharp edges.
The reason I want it to be bigger is that user base helps the single dev, with help resources, up to date gems, and jobs.
> but when I tried sprinkling a bit of react in my views
If you need only a sprinkling why not vanilla JS with Stimulus? Pulling in React for only a "sprinkling" seems like overkill.
The benefit of the current approach is that you can use any vanilla JS code, and it's especially easy if it uses ES Modules.
Also the whole point of React/Vue/Svelte is that they're all complete frameworks meant to do your whole UI. Using "just a sprinkling" of these seems like the worst of both worlds.
Dunno, my app pulls in a fairly heavy JS dependency (Echarts) and it took all of 2 minutes to set it up using Stimulus.
My friend somehow made it through to senior year without ever taking a math class. To graduate the counselor put them in the cafeteria serving lunch, which somehow counted towards a math credit.
