Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implementing a Tiny CPU Rasterizer

lisyarus.github.io

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Implementing a Tiny CPU Rasterizer

#41

Post by glowcoil »

Joker_vD wrote: post #26
gmiller123456 wrote: post #25

Earlier quoted context omitted.

A spherical cuttoff limit is also not how the human eye sees. Light can travel from any distance to reach your eye. The view frustrum is an optimization, and there will always be cases where it fails.

> Light can travel from any distance to reach your eye. Yes, but it won't necessarily register so unless we're talking about insanely bright distant object that should be visible through fog from any distance and which also is not a part of the skybox, this particular problem practically never arises. The flat far plane, on the other hand, is glaringly obvious in e.g. Minecraft, or any Unity game with first-person vi…

You're describing a problem with a particular method of fog rendering. The correct way to address that would be to change how fog is rendered. The perspective projection and the far plane are simply not the correct place to look for a solution to this.

Re: Implementing a Tiny CPU Rasterizer

#42

Post by glowcoil »

nkrisc wrote: post #28
gmiller123456 wrote: post #25

Earlier quoted context omitted.

A spherical cuttoff limit is also not how the human eye sees. Light can travel from any distance to reach your eye. The view frustrum is an optimization, and there will always be cases where it fails.

But it might more accurately reflect human visual perception. I can’t think of any case where your peripheral vision will perceive things that you won’t perceive by looking directly at them.

The only physically accurate answer for where to put the far plane is "behind everything you want to be visible". It fundamentally does not make any sense to change the shape of the far plane to "more accurately reflect human visual perception" because there is no far plane involved in human visual perception, period.

Re: Implementing a Tiny CPU Rasterizer

#43

Post by Joker_vD »

glowcoil wrote: post #41
Joker_vD wrote: post #26

Earlier quoted context omitted.

> Light can travel from any distance to reach your eye. Yes, but it won't necessarily register so unless we're talking about insanely bright distant object that should be visible through fog from any distance and which also is not a part of the skybox, this particular problem practically never arises. The flat far plane, on the other hand, is glaringly obvious in e.g. Minecraft, or any Unity game with first-person vi…

You're describing a problem with a particular method of fog rendering. The correct way to address that would be to change how fog is rendered. The perspective projection and the far plane are simply not the correct place to look for a solution to this.

I disagree. This problem exists even when the fog is completely absent and also distorts the objects at the sides of the screen regardless of the fog's presence or absence. I guess you could use fog, rendered in a particular way, to make it less noticeable but it's still there. So the root cause is the perspective projection.

Now, I've googled a bit on my own, trying all kinds of search phraes, and apparently it is a known problem that the perspective projection, when wide (about 75 degrees and up) FOV is used, will distort objects at the side of the screen. One of the solutions appears to be a post-processing pass called "Panini Projection" which undoes that damage at the sides of the screen. From what I understand, it uses cylinder (but not a sphere) as the projection surface instead of a plane.

Re: Implementing a Tiny CPU Rasterizer

#44

Post by glowcoil »

Joker_vD wrote: post #43
glowcoil wrote: post #41

Earlier quoted context omitted.

You're describing a problem with a particular method of fog rendering. The correct way to address that would be to change how fog is rendered. The perspective projection and the far plane are simply not the correct place to look for a solution to this.

I disagree. This problem exists even when the fog is completely absent and also distorts the objects at the sides of the screen regardless of the fog's presence or absence. I guess you could use fog, rendered in a particular way, to make it less noticeable but it's still there. So the root cause is the perspective projection. Now, I've googled a bit on my own, trying all kinds of search phraes, and apparently it is a…

You originally described a problem where fog had a different falloff in world space at the edges of the screen compared to the center of the screen. The root cause of that is not the perspective projection; it's how the fog is being rendered.

The issue you are describing now is called perspective distortion (https://en.wikipedia.org/wiki/Perspective_distortion), and it is something that also happens with physical cameras when using a wide-angle lens. There is no single correct answer for dealing with this: similarly to the situation with map projections, every projection is a compromise between different types of distortion.

Anyway, if you're writing a ray tracer it's possible to use whatever projection you want, but if you're using the rasterizer in the GPU you're stuck with rectilinear projection and any alternate projection has to be approximated some other way (such as via post-processing, like you mention).

Re: Implementing a Tiny CPU Rasterizer

#46

Post by xeonmc »

Joker_vD wrote: post #23

By the way, does anyone know how to modify the standard perspective projection to have a spherical cap instead of the flat rectangle as its far clipping plane? Having the flat rectangle means that you can see further from the corner of your eye than in front of you which is definitely not how the human vision works, and there are some games where this bizarre behaviour is very noticeable: you can barely see some thin…

1. you meant near clipping plane, not far

2. clipping is a GPU fixed function done on x,y,z axes separately, so it will always be a planar cut

3. the effect you're talking about can be entirely removed by setting the frustum's near plane to fit within your collision hull, e.g. for a spherical collider

    function near_plane_meters(collider_radius_meters, width_px, height_px, focal_length_px)
        return collider_radius_meters * focal_length_px / sqrt(0.25*width_px*width_px + 0.25*height_px*height_px + focal_length_px*focal_length_px)
    end

Re: Implementing a Tiny CPU Rasterizer

#47

Post by lisyarus »

xeonmc wrote: post #46
Joker_vD wrote: post #23

By the way, does anyone know how to modify the standard perspective projection to have a spherical cap instead of the flat rectangle as its far clipping plane? Having the flat rectangle means that you can see further from the corner of your eye than in front of you which is definitely not how the human vision works, and there are some games where this bizarre behaviour is very noticeable: you can barely see some thin…

1. you meant near clipping plane, not far 2. clipping is a GPU fixed function done on x,y,z axes separately, so it will always be a planar cut 3. the effect you're talking about can be entirely removed by setting the frustum's near plane to fit within your collision hull, e.g. for a spherical collider function near_plane_meters(collider_radius_meters, width_px, height_px, focal_length_px) return collider_radius_meter…

Joker_vD obviously talks about the far plane, not the near plane

Re: Implementing a Tiny CPU Rasterizer

#48

Post by gustavopezzi »

hakilebara wrote: post #33

I strongly recommend this course “3D Computer Graphics Programming”[1] from Gustavo Pezzi. It walks you through the creation of CPU rasterizer from scratch in C. I am working through it right now and I enjoy it a lot. [1] https://pikuma.com/courses/learn-3d-computer-graphics-progra...

Thank you for the mention. :)

Re: Implementing a Tiny CPU Rasterizer

#49

Post by magicalhippo »

gustavopezzi wrote: post #39
magicalhippo wrote: post #9

Nostalgia flashback. Anyone else implemented a renderer based on fatmap2.txt[1]? I came up with my own approach using bresenham and storing spans, but it was slow and sucked. Then my buddy found fatmap2.txt on a BBS and gave it to me, as I didn't have a modem at the time. It was a revelation. Programming in Turbo Pascal I was hampered by it being 16bit, but discovered I could prepend the assembly opcodes with 66h to…

Thank you for posting this. I cannot believe I did not know about it yet!

Tons of awesome demo-related tutorials floating around back then, surely some great stuff has been lost to the mists of time :(

Re: Implementing a Tiny CPU Rasterizer

#50

Post by [deleted] »

thechao wrote: post #7
ehaliewicz2 wrote: post #6

Earlier quoted context omitted.

Those were the 90s. Modern rasterizers* all use barycentric coordinate based algorithms for a few reasons. Easier to implement with proper fill conventions and multisampling, and much easier to parallelize in hardware and software. * Hardware even back in the 90s used this type of approach :)

We use barycentric (both in high performance software rasterizers and in hardware) because attribute interpolation is significantly more costly than in-bounds checking (both due to the total number of interpolates, and the precision). The in-bounds check is going to be just a few instructions (a few fmas and some sign checking) for two dimensions (x, y); whereas attribute interpolation could be needed for 30–128 'dim…

[deleted]
Post reply on HN