[HN Gopher] Software Rasterizing Hair
___________________________________________________________________
Software Rasterizing Hair
Author : ibobev
Score : 71 points
Date : 2024-09-03 08:30 UTC (2 days ago)
(HTM) web link (www.sctheblog.com)
(TXT) w3m dump (www.sctheblog.com)
| muziq wrote:
| Something about that page just makes my brain implode while
| trying to read it on my iPhone.. Sounds super interesting, but
| grey matter just doesn't function while looking at it..
| Luc wrote:
| Try Reader Mode, it fixes the awkward word and line spacing.
| waldothedog wrote:
| Had the same reaction-- Fully justified text instead of flush
| left :/
|
| It's great for magazines with small type and narrow columns
| where the letter spacing is manually dialed in but rarely works
| on the web
| waldothedog wrote:
| Coming back to say I was completely wrong, it's NOT fully
| justified, it's just very odd! Luc was right, the word and
| line spacing is quite challenging.
| davidhyde wrote:
| Very impressive! Looks like it could be used to practice hair
| cutting and to perhaps come up with some new styles. It's a shame
| that safari on iPhone is so crippled. Webgpu support in
| combination with the depth camera could turn the casual user into
| Edward scissor-hands.
| pauljara wrote:
| WebGPU is available as a preview on Safari behind a feature
| flag, so it's on its way to many users in the foreseeable
| future. Curiously, with the feature flag on, the demo works on
| desktop Safari 18.0 but not on mobile Safari 17.6 where the
| demo asks users to use Chrome.
| brirec wrote:
| I was hoping it might work on the iOS 18 beta (after turning
| WebGPU on in Settings - Apps - Safari - Feature Flags), but
| it still didn't work.
| ImHereToVote wrote:
| I remember WebGL 2.0 was feature flagged for years.
| miohtama wrote:
| For some reason, the justified text is unreadable on iPad.
| Joel_Mckay wrote:
| If you have ever had to deal with iOS/mobile web, than the
| reality of trying to deploy Media Queries hits hard.
|
| Don't take this the wrong way, but making something pretty for
| 2% to 14% of users is often low priority. Dealing with
| AppleWebKit client side is often challenging for developers
| looking to integrate normal features found in Chrome/FF.
|
| The CSS gets ugly fast... but some folks like that kind of
| perpetual project. lol =3
| lelandfe wrote:
| "Looks bad on iPad" _usually_ means "looks bad within
| 768-1024px." There are lot of other tablets out there that
| belong within that range. (iPad-specific problems do exist
| and are a bummer)
|
| > The CSS gets ugly fast
|
| Mobile-first keeps things happy if you're writing one big CSS
| file or even stuff like SCSS. Use as little specificity as is
| needed, and generally use min-width instead of max- so that
| your CSS is written "mobile first," in a cascading manner.
|
| Responsive and readable CSS is possible at scale, it just
| requires some dedication.
| Joel_Mckay wrote:
| The better frameworks I've seen used a template abstraction
| layer to render different interfaces for mobile, pad, and
| desktops.
|
| Every iPhone version was slightly different, and if the
| scaling is wrong the GUI glitches look like an amateur
| hatchet job. =3
| darrinm wrote:
| Amazing write up as well as the other implementations and
| writeups by the same author it links to.
| phkahler wrote:
| If software rasterization is good for tiny triangles then maybe
| it's time for ray tracing. It scales better with large scenes and
| loves lots of CPU cores.
| LoganDark wrote:
| ShaderToy already has GPU ray tracers and the main problem is
| branching control flow. When you draw triangles you can give
| the same exact operations to a chunk of cores and GPUs are very
| good at that. When you ray trace, or at least when you path
| trace (multiple bounces per ray), each ray can go in any number
| of directions, and they diverge very quickly with any kind of
| reflection or diffusion.
| dennis_jeeves2 wrote:
| Now, if only it to grow hair on bald patches...
| rivo wrote:
| I programmed something like that back in 1999:
|
| https://kuederle.com/university/fur/improvedtext.jpg
|
| Each hair consisted of four segments. All segments were sorted,
| then drawn back to front. Each segment was drawn as an anti-
| aliased line (no hardware support for this back then, so I had to
| invent my own line renderer). So a hair could not be thicker than
| one pixel but that's a reasonable assumption at a certain
| distance. This made it reasonably fast given the hardware at the
| time.
|
| I've been wanting to reimplement this using modern shaders, to
| see how fast it would be these days, but haven't gotten around to
| it yet.
| Log_out_ wrote:
| Hair is a spline alright, but surface is defined by the head
| normal to which the vector gimbals downmost vector defines the
| direction of the strain plane should fall. Then apply physics to
| the spline.
___________________________________________________________________
(page generated 2024-09-05 23:01 UTC)