Live data from Hacker News

I'm making 30 VR projects in 30 days to learn

risonsimon.com

11–20 of 39 posts

Re: I'm making 30 VR projects in 30 days to learn

#11
I do like it when people set themselves challenges like this. Clear beginning and end, finishing something in combination with iterative learning is very satisfying. A bit like a hackaton or a game jam. But this made me think, because in a way it limits yourself in what you can do with what you previously learned. The more you learn the more complex projects you can create and halfway through you can create something which doesn't fit in a day anymore; complexity pushes build time up exponentially. E.g. it needs some extra tooling for generating procedural content. So what I propose is instead of 'over the course of 30 days I will every single day finish a project', why not follow the Fibonacci sequence: I start with nothing (procrastinating), next a one day project, followed by another single day effort. Stepping up with a 2 day project -> a big 3 day project -> 5 day full blown project -> 8 day epic. And finally: a full 13 days working on a single masterpiece! (33 days in total).

Re: I'm making 30 VR projects in 30 days to learn

#12
post #8
post #6

Earlier quoted context omitted.

You render twice per frame: half the "screen" rendered with a camera at ([-eyeOffset, 0, 0] * cameraRot) and the other rendered with a camera at ([+eyeOffset, 0, 0] * cameraRot). The main thing is this has some surprising performance implications (such as geometry complexity being more important than shader fillrate). You also need to keep an untraditionally high frame rate without dropping frames (90 FPS on the desk…

There is one major difference in terms of graphics programming - deferred rendering doesn't work well in VR since it's incompatible with proper multisampled antialiasing, and the edge-detect and/or temporal AA methods typically used instead are too blurry when combined with the low perceived resolution of today's VR headsets. For this reason there's been a trend back towards forward rendering, with some modern twists…

In the youtube video, they mention that moving lights can't cast shadows. https://youtu.be/6kfMVxNSowM?t=3276

That's a significant limitation for a modern technique.

Here's the full algorithm for anyone curious:

> The Forward Renderer works by culling lights and Reflection Captures to a frustum-space grid. Each pixel in the forward pass then iterates over the lights and Reflection Captures affecting it, sharing the material with them. Dynamic Shadows for Stationary Lights are computed beforehand and packed into channels of a screen-space shadow mask, leveraging the existing limit of 4 overlapping Stationary Lights.

Re: I'm making 30 VR projects in 30 days to learn

#13
post #4

Can anyone explain what's radically different in "VR dev" compared to "3D dev" (from the graphics programmer perspective)?

From the graphics programmer perspective? Nothing radically different at all. It's the same real-time rendering techniques that have existed for a while. VR is only different in design methodology really (and performance requirements, as noted in another comment). But in terms of programming, there's no huge leap between graphics programming for a flatscreen or VR game.

Re: I'm making 30 VR projects in 30 days to learn

#14
post #8

Earlier quoted context omitted.

There is one major difference in terms of graphics programming - deferred rendering doesn't work well in VR since it's incompatible with proper multisampled antialiasing, and the edge-detect and/or temporal AA methods typically used instead are too blurry when combined with the low perceived resolution of today's VR headsets. For this reason there's been a trend back towards forward rendering, with some modern twists…

In the youtube video, they mention that moving lights can't cast shadows. https://youtu.be/6kfMVxNSowM?t=3276 That's a significant limitation for a modern technique. Here's the full algorithm for anyone curious: > The Forward Renderer works by culling lights and Reflection Captures to a frustum-space grid. Each pixel in the forward pass then iterates over the lights and Reflection Captures affecting it, sharing the m…

That was a limitation of the initial implementation in UE4.14, not the technique itself. They iterated on it in UE4.15: https://www.unrealengine.com/blog/unreal-engine-4-15-release...

> Forward renderer now supports shadowing from movable lights and light functions.

> Only 4 shadow casting movable or stationary lights can overlap at any point in space, otherwise the movable lights will lose their shadows and an on-screen message will be displayed.

Re: I'm making 30 VR projects in 30 days to learn

#15
post #14

Earlier quoted context omitted.

In the youtube video, they mention that moving lights can't cast shadows. https://youtu.be/6kfMVxNSowM?t=3276 That's a significant limitation for a modern technique. Here's the full algorithm for anyone curious: > The Forward Renderer works by culling lights and Reflection Captures to a frustum-space grid. Each pixel in the forward pass then iterates over the lights and Reflection Captures affecting it, sharing the m…

That was a limitation of the initial implementation in UE4.14, not the technique itself. They iterated on it in UE4.15: https://www.unrealengine.com/blog/unreal-engine-4-15-release... > Forward renderer now supports shadowing from movable lights and light functions. > Only 4 shadow casting movable or stationary lights can overlap at any point in space, otherwise the movable lights will lose their shadows and an on-sc…

Excellent! Thanks for passing along the technique. This is an interesting evolution.

Re: I'm making 30 VR projects in 30 days to learn

#16

I do like it when people set themselves challenges like this. Clear beginning and end, finishing something in combination with iterative learning is very satisfying. A bit like a hackaton or a game jam. But this made me think, because in a way it limits yourself in what you can do with what you previously learned. The more you learn the more complex projects you can create and halfway through you can create something…

That is a interesting approach. Thanks.

Re: I'm making 30 VR projects in 30 days to learn

#20
post #3
post #2

What's holding the camera in the day 2 project?

I'm guessing the rod holding it is patched out using software.

Yea that is generally the approach, the tripods are a common artifact in 360 degree videos and photos, if is of professional quality it gets blurred or patched some other manner.
Post reply on HN