pouët.net

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. :)

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..

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. :-(

Nice write up, thanks

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?

Neat. Thanks for sharing!

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.

nice write up!

👍

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

Thanks for the read!

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.



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.


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.


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.


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.


Excellent! Great to see others creating new things immediately!

It's great you are making these write-ups. Felicitations!

This is awesome! Loved the demo, really cool to see how much effort went into it. So much interesting information :)



+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.

Thank you. :)


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.


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.