pouët.net

Go to bottom

Another 64k write up

category: general [glöplog]
 
Good morning all,

LLB and I have been working on a behind the scenes article, detailing some of the design decisions and technical solutions used in H - Immersion last year. You can read it here:

--> A dive into the making of Immersion

I hope you'll enjoy it. We have more in the making, including some fancy effect break off video. :)
added on the 2018-03-18 06:01:01 by Zavie Zavie
On my phone the site layout looks like scene poetry off an orange demo. On landscape it looks fine though.

I'm always glad for write-ups, going to dive in now..
added on the 2018-03-18 06:16:27 by sol_hsa sol_hsa
Thanks for the feedback, I've been sent a screenshot by a friend as well. I think we need to update Wordpress and/or the theme, because it's definitely broken. :-(
added on the 2018-03-18 06:44:53 by Zavie Zavie
Nice write up, thanks
added on the 2018-03-18 12:51:21 by leGend leGend
Thanks, Zavie. Many interesting ideas. I especially like the approach of using real-time tweakable values (directly in C++ code) instead of writing a demotool. How about camera movement and duration of the scenes? Did you also tweak values directly in the code or just used some timeline editor?
added on the 2018-03-18 14:36:01 by tomkh tomkh
Neat. Thanks for sharing!
Code:_TV(1.001)
added on the 2018-03-18 15:34:20 by neoneye neoneye
Very interesting! Thanks for writing this. I love the size consumption diagram.

It shows that you really worked hard on the intro. The volumetric lights looked so great and it's cool that you've got some actual science (the phase function) to back you up :) I'd watch an ambient remix of the intro with only different camera shots of underwater weeds casting those smooth smooth shadows on the ocean floor.

Did you use generated meshes for the scenes and raymarching only for the volumetric light? I guess you did because otherwise rendering the shadow map would've been pretty costly! Were the meshes generated with C++ CPU code that you had to recompile after each change?

I'd also like to hear how your tweakable values worked in practice. In our code it got a bit too verbose for my taste. The main annoyance was the need for the GET_VAR(x) macro to access the values, see the link for details. In the end we didn't even use the tweak variables much and just put a generic "param1" track in GNU/Rocket instead. You could still tweak it during runtime and also animate it.

The ocean waves. You really nailed that look. It's something I have wanted to work on my self for a long time but haven't gotten around to it. Great work all around.
added on the 2018-03-18 16:05:08 by cce cce
nice write up!
added on the 2018-03-18 17:09:55 by psenough psenough
👍
added on the 2018-03-18 20:28:11 by psonice psonice
After reading this great article, I have ported the tweakable values to swift.
added on the 2018-03-18 21:29:21 by neoneye neoneye
Thanks for the read!
added on the 2018-03-18 21:51:21 by numtek numtek
Quote:
How about camera movement and duration of the scenes? Did you also tweak values directly in the code or just used some timeline editor?

The camera data is stored in a simple JSON file during development and, as described in the article, that file is reloaded automatically whenever it's changed. For the release build it's then quantized and exported as a static array in a C++ file. We do that for all the timeline related data as well.
So camera editing is a part which I think we need to improve. At the moment we are just interpolating between camera positions and orientations, and cupe keeps arguing we should all use a crane model. :) We just place the camera in first person view, add the new keyframe to the file, and so on. For other timeline curves, we have a curve editor.


Quote:
It shows that you really worked hard on the intro. The volumetric lights looked so great and it's cool that you've got some actual science (the phase function) to back you up :) I'd watch an ambient remix of the intro with only different camera shots of underwater weeds casting those smooth smooth shadows on the ocean floor.

Thank you so much for the comment, you made my day. <3
The rendering is general is mostly physically based. We have some fudge values here and there, but we're still trying to stay grounded and have energy conservation.

Quote:
Did you use generated meshes for the scenes and raymarching only for the volumetric light? I guess you did because otherwise rendering the shadow map would've been pretty costly! Were the meshes generated with C++ CPU code that you had to recompile after each change?

So yes our rendering is a traditional polygon based one, with traditional shadow maps (using VSM). Volumetric lighting uses a combination of ray tracing (to hit the light cone) and ray marching (to tap in the shadow map) but that's just for that effect. I like the idea of mixing techniques though.
Meshes are generated during the loading, from C++ code. Since we have hot C++ recompilation and building a mesh is pretty fast, we don't have to restart the demo or anything (although we still don't have a satisfactory solution for code shared between meshes). We have an article on the topic in the making, which we should publish soon.

Quote:
I'd also like to hear how your tweakable values worked in practice. In our code it got a bit too verbose for my taste.

Ok I can see why you are unhappy. In our case it is completely transparent: we just have one include, then we just use _TV(blah) in the code, so it's really unintrusive. The only problem is the current implementation is slow, so when it's used in critical loops it can easily bubble up in the profiler (but I did some tests with a different data structure and there was some improvement). Feel free to show up at our table at Revision if you want to see some code.

Quote:
The ocean waves. You really nailed that look. It's something I have wanted to work on my self for a long time but haven't gotten around to it. Great work all around.

Thank you. :) We took some inspiration from this awesome shader on Shadertoy, which someone took the trouble of documenting by the way. Actually I should add that link to the article.

Quote:
After reading this great article, I have ported the tweakable values to swift.

Excellent! Great to see others creating new things immediately!
added on the 2018-03-19 05:21:15 by Zavie Zavie
It's great you are making these write-ups. Felicitations!
added on the 2018-03-19 07:51:15 by Adok Adok
This is awesome! Loved the demo, really cool to see how much effort went into it. So much interesting information :)

Quote:
cupe keeps arguing we should all use a crane model.


+1 to this, crane cameras are insanely useful - you'll honestly never look back!

Would be interested to hear why you guys edit plain JSON instead of using something like Rocket (or do you?)... Personally I find Rocket really useful, although nothing like a proper spline editor.

Super keen for the texture/mesh posts, I'm really interested to see how you guys handle that.
added on the 2018-03-20 12:16:18 by cpdt cpdt
Thank you. :)

Quote:
Would be interested to hear why you guys edit plain JSON instead of using something like Rocket (or do you?)... Personally I find Rocket really useful, although nothing like a proper spline editor.

For the timeline curves, we have a separate spline editor. It's a bit messy but it does the job.
For the camera, we haven't clearly defined yet what we need. The main problem, I think, comes from editing: you might want to cut in the middle of an interpolation, or adjust the duration of a shot but keep certain things in place. How do you do that without having to redo the shot entirely? We don't have a good solution yet, so it's a mix of shortcuts and manual copy-paste.

Quote:
Super keen for the texture/mesh posts, I'm really interested to see how you guys handle that.

It's mostly written and at this point it's just a matter of taking a few screenshots to illustrate, so it should be out soon enough.
added on the 2018-03-21 15:06:08 by Zavie Zavie

login

Go to top