Claybook [XO, PS4, PC, NX]

UE 4.13 (https://www.unrealengine.com/en-US/blog/unreal-engine-4-13-released) introduced shadow map caching for local lights (point and spot), but the caching doesn't support the sun light yet. Would be nice if they introduced sun light shadow map caching for distant geometry. The lighting shader would sample this shadow map for geometry that's further away than the last shadow map cascade. It would obviously need a different projection matrix than the cascades and higher resolution (8k*8k at 16bpp is pretty good).

One thing I've always wondered. Does Unreal Engine allow developers to submit things back into UE? I know Lionhead seemed to contribute something for GI, but it doesn't seem to be common. Are companies just tight with their custom code? I can see what companies wouldn't want to give their customizations back to UE for them to license out for actual money.
 
One thing I've always wondered. Does Unreal Engine allow developers to submit things back into UE? I know Lionhead seemed to contribute something for GI, but it doesn't seem to be common. Are companies just tight with their custom code? I can see what companies wouldn't want to give their customizations back to UE for them to license out for actual money.
Unreal Engine source code is in github. They accept pull requests (https://trello.com/c/1bE9BFkX/47-ue4-pull-requests). NDA code changes (to console backends) of course can't be submitted to public github. UE team has been very responsive in fixing bugs I have reported. I have sent them some code as well. I have been happy about the quality of their support.
 
This was just the first announcement. We haven't yet decided on the launch date. Will let you know when we know more. Still lots of things to do.

Can't wait.

I've got a question that I've been meaning to ask, but keep forgetting. Would it be possible to port this to the Switch? And if so, would that be something you'd look into after launch?

I've just been thinking that this looks like it would be such a wonderful game to play on a portable gaming device. I can just imagine sitting outside under a tree playing this. Seems like it'd be so peaceful and zen.

Regards,
SB
 
I've got a question that I've been meaning to ask, but keep forgetting. Would it be possible to port this to the Switch? And if so, would that be something you'd look into after launch?

I've just been thinking that this looks like it would be such a wonderful game to play on a portable gaming device. I can just imagine sitting outside under a tree playing this. Seems like it'd be so peaceful and zen.
The problem with Switch is that we run all physics and fluid simulation, clay world deformation and some game logic on GPU. This takes considerable amount of GPU time. The cost of these tasks doesn't scale down with resolution.

Some rough calculations based on Eurogamer specs. Take as grain of salt, I have never worked on actual Switch devkit: In handheld mode Switch GPU is downclocked by 50%. If we assume that simulation took for example 30% of GPU time in docked mode, in handheld mode it would roughly take 60% of the GPU time. And that remaining 40% is equivalent of 20% of GPU time in docked mode (double GPU clock). So we'd have to scale down the visuals by 3.5x in handheld mode (compared to the usual 2x). This is in addition to the Switch GPU being significantly less powerful than Xbox One GPU even in the docked mode.

I however do agree that Switch would be a perfect platform for our game. But it isn't possible to bring the same game on Switch by simply dropping the image quality. Nintendo clearly understands that scaling game logic down is hard, so they don't down-clock the CPU while in handheld mode. This is great... for other developers. But unfortunately our game logic runs on GPU.
 
The problem with Switch is that we run all physics and fluid simulation, clay world deformation and some game logic on GPU. This takes considerable amount of GPU time. The cost of these tasks doesn't scale down with resolution.

Some rough calculations based on Eurogamer specs. Take as grain of salt, I have never worked on actual Switch devkit: In handheld mode Switch GPU is downclocked by 50%. If we assume that simulation took for example 30% of GPU time in docked mode, in handheld mode it would roughly take 60% of the GPU time. And that remaining 40% is equivalent of 20% of GPU time in docked mode (double GPU clock). So we'd have to scale down the visuals by 3.5x in handheld mode (compared to the usual 2x). This is in addition to the Switch GPU being significantly less powerful than Xbox One GPU even in the docked mode.

I however do agree that Switch would be a perfect platform for our game. But it isn't possible to bring the same game on Switch by simply dropping the image quality. Nintendo clearly understands that scaling game logic down is hard, so they don't down-clock the CPU while in handheld mode. This is great... for other developers. But unfortunately our game logic runs on GPU.

Out of curiosity, is it a possibility to move that GPU game logic back over to the CPU? Do you think there would be enough headroom, or were you running it on the GPU in order to CPU load in the first place? (Or is it to avoid too much cpu <-> gpu communication maybe?)

If not.. , assuming it's possible, maybe a 30 fps handheld version, perhaps just in handheld mode, would be acceptable?

(I don't have a switch btw, I'm really just wondering)
 
Out of curiosity, is it a possibility to move that GPU game logic back over to the CPU? Do you think there would be enough headroom, or were you running it on the GPU in order to CPU load in the first place? (Or is it to avoid too much cpu <-> gpu communication maybe?)
CPU<->GPU communication is already somewhat a bottleneck and I only move 6 MB data per frame from GPU to CPU. Coherent data bus between GPU and CPU is pretty slow. I only move low res volume data and aggregate simulation data from GPU->CPU. We have 16384 particles per deforming mesh and lots of fluid sim particles that interact seamlessly with the physics particles. Physics sim state is roughly 50 MB. Moving that to GPU every frame would be awkward (that's equivalent to uploading twelve new 2048x2048 DXT compressed textures every single frame to GPU).

I am afraid that 4 ARM cores at low clock rate isn't enough to run the simulation, even if it was 100% NEON optimized (written as ISPC code). If we had 16-core Threadripper or i9 with AVX2 (8-wide float+int ops + gather), things would be different however. One thing that CPU is especially bad is trilinear filtering of SDF volume. On CPU side it requires 8 memory fetches (not contiguous = need gather) + lots of weight and blending math. SDFs are used for all collisions and gradient calculations (gradient = 6 trilinear filter ops). This is where GPU hardware trilinear filter units shine.
If not.. , assuming it's possible, maybe a 30 fps handheld version, perhaps just in handheld mode, would be acceptable?
Rendering could run at 30 fps, but physics needs to run at higher frame rate. Initially we had 240 Hz physics, but I switched from gauss-seidel solver to shape match solver and dropped simulation to 60 Hz. But can't go below that, or particles start to tunnel through thin walls. If we again assume that physics takes 30% of the GPU frame time on docked Switch (at 60 fps). At 30 fps it would still take 30% of the frame time (frame is 2x longer, but need to run two physics ticks in each graphics frame) in docked mode and 60% of frame time in handheld. That remaining 40% in handheld mode is roughly equivalent to frame budget of a normal 60 fps game (but we would only run at 30 = BAD). So 30 fps doesn't free as much resources as it normally does, as the simulation workload per rendered frame doubles.

But obviously we could simplify the SDF meshes (less particles = more coarse deform) and have less fluids in Switch levels if we wanted to do that. And obviously we could further optimize the simulation shaders. But with one GPU programmer this takes significant time. However after the main game launch (Xbox, PS4, PC) we have more time. Switch version at later date is definitely a possibility. But it needs to be a custom version specifically architected for that platform.
 
Last edited:
Hey sebbbi, since I cannot find it in here, but over on reddit a while ago: You mention you use async compute only on console - why not on PC? Lots of hardware out there that could benefit after all. Or is performance good enough without it already?
 
Hey sebbbi, since I cannot find it in here, but over on reddit a while ago: You mention you use async compute only on console - why not on PC? Lots of hardware out there that could benefit after all. Or is performance good enough without it already?
We now also support async compute on PC. Recently added DirectX 12 support. Currently async compute gives 7% faster performance on Radeon RX 480, but it is a direct console port with no tweaking. I would expect bigger gains later.
 
Can't wait to see this. I must say, Claybook really looks like it's going to be much fun!

(btw: we have Trials: Fusion as Covermount this month in the making/next month on shelves. :))
 
I am pleased to announce that Claybook is going to be available on October 18th on Steam early access.

Steam game page with new info:

New trailer:

The current plan is to have 3-6 month early access period on PC followed by the game launch on all platforms (early 2018).
 
Very cool! Bit concerned about the 'Play. Create. Share' tag-line though, as that's exactly what LBP had. Hope it won't cause issues. If you're wanting to use that as your main marketing concept, you may want to find another phrasing.
 
Claybook: It's not Facebook

Will definitely pick up in early access, can't wait to play it with my kids. Have 2 controllers on my PC now for local co-op.

It supports 21:9 right? :)
 
Back
Top