Valve Hardware announcement — discussion

RmbRT said:
I welcome that move more than foveated rendering, because it will force games to do native 4K rendering, and only the image streaming into the VR goggles will utilise the eye tracking.

If there is an eye tracker, i want to use it to reduce the workload. Rendering the whole Image at 4K although you only need a single digit percentage at this resolution is a waste of power and money we do not have.
But as long as it's only a VR topic i won't complain.

RmbRT said:
Another thing I found interesting is that the PC/console they're selling will have a GPU that has 8 GiB of VRAM, when nVidia just recently said they want to phase out of 8GiB models and make 16GiB the standard.

Like with Steam Deck Valve keeps the specs at a minimum. Depends on pricing how good this is.
I assume it will compete with PS6 which is twice as powerful but costs less.
It's a good start regardless.

Maybe Sony starts considering opening up PS platform to compete plans from Steam and MS.
It's wishful thinking, but assuming PS6 goes up in price too, allowing people to use it as a computer would compensate.

RmbRT said:
The controller seems great

Yeah, trackpads! \:D/
Though, two sticks and two pads is overkill imo. Jimi could play a right handed guitar quite well.

RmbRT said:
I think they started a move towards more affordable gaming with lower hardware requirements, and a more standardised hardware environment

Depending on how you look at it, you can easily say the opposite as well. We have one more OS to support, we have increased range of HW power across devices all meant to run the same game.

But it's the right direction and an attempt to cover the price / performance sweet spot. The PC platform has to change, or it needs an affordable and reasonable replacement. I'm willing to sacrifice PC upgrade capabilities and dGPU for a cheaper and smaller device which i can use for all my computing and gaming needs.
Though, i'm afraid it will still take 5 - 10 years until we really get there.

JoeJ said:
If there is an eye tracker, i want to use it to reduce the workload. Rendering the whole Image at 4K although you only need a single digit percentage at this resolution is a waste of power and money we do not have. But as long as it's only a VR topic i won't complain.

I'm sure you also get access to true foveated rendering if you run natively on the VR goggles, instead of streaming from a PC. But that requires support from the game / engine. Maybe it can also work for the game directly, but then the game also directly has to target that hardware and the accompanying SDKs. Which is fine, I guess. But I like how it makes the best use even out of games that don't support it.

JoeJ said:
It's wishful thinking, but assuming PS6 goes up in price too, allowing people to use it as a computer would compensate.

True, but then again, the playstation has its own locked-in OS and they definitely don't want you to run arbitrary software on it. And even if they open it up, it would have to be linux or windows compatible, otherwise people wouldn't really be able to do anything with it, as you need the software to go along with it for that move to be meaningful.

The LCD steam deck is affordable, I don't think I would be buying the OLED version that costs up to 62% more. And if you constantly keep it plugged in, you could use it as a PC or laptop replacement, just like I chose to get a laptop instead of a tower PC so that I can also work when I visit my parents or something. The OLED version, especially the 1TiB version, is a luxury product, so for a fair comparison with consoles, I would refer to the 512GiB OLED or the LCD version. As a console, the deck is lower end in performance, but that's to be expected of a handheld. I think the whole value proposition of the steam hardware suite is if you are planning on making the jump to a new machine anyway, and then simply use one of those devices instead of getting a new tower PC, and weren't aiming for high end hardware to begin with.

JoeJ said:
Yeah, trackpads! \:D/ Though, two sticks and two pads is overkill imo. Jimi could play a right handed guitar quite well.

If the game properly recognises the trackpads, and treats them distinctly, that could open up a lot of possibilities to more complex / immersive control schemes. It doesn't have to be used to move a cursor, necessarily. It could be used for gestures, for tapping, etc. I don't know what kinds of inputs you can get from them, though, and whether they do multi-touch, etc.

JoeJ said:
We have one more OS to support, we have increased range of HW power across devices all meant to run the same game.

It natively emulates Windows via Proton, so you don't have to support the SteamOS / Linux directly.

But I think this is the first time a middle class gaming hardware audience has been firmly established. You now got the ever-more expensive flagship consoles and high end gaming rigs with their 16GiB or even 32GiB VRAM, then you get the gabe cube and the deck with up to 8GiB VRAM (the deck technically doesn't have VRAM, but still, for the sake of the argument…), and then you get the 512MiB to 2GiB that you find on low end hardware such as laptops or old machines. Which is also a section of 10-20% of the steam audience.

Before that, you only really had the “runs on a potato” category, and then the occasional “might run on 8GiB VRAM” title and then the “requires 16GiB VRAM” AAA mainstream section of games. And games from the old era when even high end GPUs didn't really have that much VRAM.

Now, a new audience and expectation has been established that targets 8GiB VRAM. It will probably live alongside the potato and the battle station audiences. Which one will end up becoming the most dominant over the next few years, I don't know.

JoeJ said:
I'm willing to sacrifice PC upgrade capabilities and dGPU for a cheaper and smaller device which i can use for all my computing and gaming needs.
Though, i'm afraid it will still take 5 - 10 years until we really get there.

I'm currently on a ~500€ laptop and it covers all my needs. Having both a tower and a laptop is a huge hassle because you'd have to constantly sync your stuff. I think tower PCs are only really adequate nowadays if you need a high power work station, or never really need to take your main PC with you. As soon as you need your work machine on travels or something, a laptop or maybe steam deck as a portable PC become reasonable. Especially if you connect the deck to a TV so that you can get a proper screen size to work with. On the other hand, a console is purely for entertainment and you will still need your separate work device, at least for the for the foreseeable future. A small PC like the steam cube is also portable at 16cm, you could fit that into a backpack. And the deck could even be used on the train with a keyboard so you wouldn't even need to own a laptop anymore. I think that's where a tiny PC or handheld really starts to become valuable. At that point it would just come down to whether you prefer a laptop or a handheld, or whether you only need to relocate your work PC from time to time but don't need to operate it while you are on the road/train. Because transporting a tower PC sucks. This ecosystem that Valve is building here is basically enabling work/gaming-capable PCs to become either handheld or small enough to be easily transportable even on foot, which was previously always a big hassle with computers. In that sense, it's not really to be viewed as a competitor of consoles, I think. The real value is that you now get to choose between laptop, portable tower, and handheld PCs. It's a really weird blend, and I'm looking forward to seeing how it all will play out and what people will end up doing with that. Like how smartphones also made lots of people opt out of computers, this might also change the role of traditional computers and (handheld) consoles.

JoeJ said:
we have increased range of HW power across devices all meant to run the same game.

I think it is high time for game studios to earnestly accept that reality again and to try to make the game run as well as possible on as little hardware as possible, and then also make it look as good as possible on as much hardware as is available. It's always easy to make it more fancy by using more power and more memory. But making it run well or at all on lower-spec machines is something you have to plan for from the get-go, which everyone nowadays is just too lazy to do. I think it's reasonable to expect that from a $300M budget project, though.

RmbRT said:
Maybe it can also work for the game directly, but then the game also directly has to target that hardware and the accompanying SDKs. Which is fine, I guess. But I like how it makes the best use even out of games that don't support it.

The API of an eye tracker only has to give screen x and y coordinate for a minimum, so APIs shouldn't be a problem even across platforms.

But ofc. foveated rendering is still an open problem and research topic.
Currently you can use VRR to reduce shading costs, but does not help with geometry. Iiirc VRR on PSVR gives them a win of 25-50%.
For proper foveated rendering we need new methods for continuous LOD and rasterization free of aliasing. Then we can hope for a speed up of 10-20.

But this revolution seems quite distant. Tracking eyes from the distance of the display is likely a hard problem, current GPU arch misses the point. Actually, this would be an opportunity for an entirely new platform.

RmbRT said:
And even if they open it up, it would have to be linux or windows compatible

They could use Linux like Valve does. And they surely could keep their DRM unaffected.
If they want to stay relevant they should open up. Otherwise they'll do a Sega at some point.

RmbRT said:
I don't know what kinds of inputs you can get from them, though, and whether they do multi-touch, etc.

Idk either. But i have tried a classic Steam Controller and assume it's still the same tech. It was not as precise as a mouse, and playing FPS was not great. But it was good enough, and maybe with some practice it gets better.
But multi touch probably does not work. It also makes little sense, because you have only the thumb on it. The other fingers are below and can't conveniently reach it.
I also don't see many options from 2 x touchpad vs. stick + touchpad.
Now the controller is quite bulky and more costly, for the only real advantage of left handed support.

RmbRT said:
It natively emulates Windows via Proton, so you don't have to support the SteamOS / Linux directly.

Haha, ‘native emulation’, i would not have expected this from a FPGA guy : )
It's great they make this work.
But the goal is to get rid of Windows. So personally i would make a native Linux version, to avoid the runtime API conversation, and mostly: To feel free \ : ) /

RmbRT said:
Which is also a section of 10-20% of the steam audience.

Do we know anything about how much games this section still buys?
Is it maybe dead accounts and they have long upgraded?
Is it the laptops they use in bed to watch TV, but they also have bulky gaming rig in their basement?

Or do they get their statistics from contacting random active Steam users asking to fill the survey?
Afaik that's what they do, and if so the statistics work without any additional weighting.

RmbRT said:
As soon as you need your work machine on travels or something, a laptop or maybe steam deck as a portable PC become reasonable.

I want a mini PC. With power, and cooling, so i can enjoy gfx. The Steambox in question is actually what i want.
But i don't want to pay for a laptop as well, just so that i can code in bed as well. Although, i would code in bed if i had a laptop.

Thus i was thinking, it would be nice to have a device of display and keyboard, which i can plug into the mini PC.
Then i only need to carry the PC, plug it into power, and connect the keyboard.
Yes, i need to carry more stuff, but i don't need to sync anything. So this would be really nice accessory for mini PCs.

RmbRT said:
And the deck could even be used on the train with a keyboard so you wouldn't even need to own a laptop anymore.

No. You can not sit in the train with a bulky Steam Deck to scroll tiktok. Women will think you're still a kid, run away, and humanity extincts.
Just keep scrolling on your slick iPhone. ;D

RmbRT said:
This ecosystem that Valve is building here is basically enabling work/gaming-capable PCs to become either handheld or small enough to be easily transportable even on foot, which was previously always a big hassle with computers.

iPad.
It's a little too late for Gabe i'm afraid. But who knows…

RmbRT said:
I think it is high time for game studios to earnestly accept that reality again and to try to make the game run as well as possible on as little hardware as possible

I think they can change their mind in this sense quickly, and their next game can be already for low power targets.
And they will do this, as soon as their market analysis tells them so. So it's the players who decide this, not the devs.

But the question is: Can we scale the same game to any power level, or do we need to fragment the market further into mobile, low, and high power tiers?
It's this question which makes me optimistic about a rise of new platforms, a revolution, some real changes and new excitement.

RmbRT said:
But making it run well or at all on lower-spec machines is something you have to plan for from the get-go, which everyone nowadays is just too lazy to do. I think it's reasonable to expect that from a $300M budget project, though.

It's not so simple i'm sure.
If your minimum specs include low power handhelds, this means less gfx, less physics, less NPCs, smaller world, etc. So you simply can't make the same game you could make when targeting PS5 and up.
If your minimum was PS5, and now you want a mobile version of your very successful game too, you need to reduce the game. Which is some work, so your cost is no longer 300M but 300M + X.

Now you may argue ‘i don't need fancy gfx and simulation - it's not what makes a game good’, and yes with this mindset your expectation holds.

But the other guy will be sad his new RTX 5090 Dubai edition now needs external heating to get up to operation temperature, and no rays glitter on his screen, no beautiful AI girl faces are patched over ugly triangle meshes, and wheel suspension isn't simulated either. No immersion, he frowns.

It seems everybody picks his own point from this scale for a reasonable expectation, which causes friction and dissatisfaction on all ends.
Market fragmentation would fix this.

Time and time again folks salivate over new hardware drop catering to chasing the endless technically progress ( HW will continuously improve over time). In the end as we've seen OVER and OVER again, the issue is NEVER the HW. You could have a super-computer in the palm of your hand or on a desk, but if there is no software support( ‘good’ games), then it becomes an expensive and or exotic paper-weight. I have more fun playing Tetris on the original Gameboy than some of the games being release today with all the bells and whistles. I do understand that what makes a ‘great game’ is HIGHLY subjective, but for each definitions of a ‘great game’ I guarantee polling will show that the user/player would take that over shiny new HW.

JoeJ said:
Haha, ‘native emulation’, i would not have expected this from a FPGA guy : ) It's great they make this work. But the goal is to get rid of Windows. So personally i would make a native Linux version, to avoid the runtime API conversation, and mostly: To feel free \ : ) /

Haha, yeah, kind of ironic. And I agree, native linux is best long-term, especially since Windows becomes more and more hostile to users every day.

JoeJ said:
Do we know anything about how much games this section still buys? Is it maybe dead accounts and they have long upgraded? Is it the laptops they use in bed to watch TV, but they also have bulky gaming rig in their basement?

Maybe. What's for certain is that they aren't buying AAA games for those devices, at least. I think they regularly renew the numbers though.

JoeJ said:
But i don't want to pay for a laptop as well, just so that i can code in bed as well. Although, i would code in bed if i had a laptop.

Actually, the end game of that is to either have a beamer that uses your ceiling as screen, and a split keyboard, so that you can comfortably lie on your back while typing without getting carpal tunnel. Or, probably cheaper, get a VR headset instead of a beamer. Even a true full HD beamer with 60 Hz is pretty expensive, and true 4K even more so. A 2×4K VR headset would be much cheaper and quieter. The question is just whether you can operate the steam VR goggles while lying down on the back of your head, or whether that causes issues or pressure pain. I have been considering this option seriously because of my back problems.

JoeJ said:
No. You can not sit in the train with a bulky Steam Deck to scroll tiktok. Women will think you're still a kid, run away, and humanity extincts. Just keep scrolling on your slick iPhone. ;D

Luckily, I never got into that site. I still got time to find a proper wife so it's alright if they run away for now, haha. But I was more thinking about using the PC to program while on the train, not to browse. But I guess that's even worse, haha.

JoeJ said:
iPad. It's a little too late for Gabe i'm afraid. But who knows…

Yeah kind of like what tablets and smartphones did to computers, but more gaming-ready and without the need for jailbreaking. But the direction is quite similar, however, that doesn't mean the impact will be the same.

JoeJ said:
I think they can change their mind in this sense quickly, and their next game can be already for low power targets. And they will do this, as soon as their market analysis tells them so. So it's the players who decide this, not the devs. But the question is: Can we scale the same game to any power level, or do we need to fragment the market further into mobile, low, and high power tiers? It's this question which makes me optimistic about a rise of new platforms, a revolution, some real changes and new excitement.

True, they only have to want it. And yes, performance scaling is not an issue. Epic really wanted to pull of Nanite and Lumen, so they did that. If now someone really wanted to pull off the opposite thing with an engine, trying to scale down assets, maybe reduce graphical precision where necessary, etc., creating maybe inferior outcomes but with quite a bit less data or effort going into it, etc., that's definitely possible. Even just LOD and mipmap reduction would already go a long way in reducing memory footprints. There is also almost always a less accurate, but much more simple solution for almost all graphical effects. And downscaling and upsampling of effects has already been established, too, so that can also be used more aggressively. Global real-time illumination isn't always essential, and instead of shadow maps, sometimes you can also just use an untextured decal mesh that gets projected onto the scene, which can even achieve great sharp outlines. Of course it also has lots of shortcomings, but it would be much easier on the GPU than projecting depth textures from multiple cameras onto the scene.

By (aggressively, if necessary) scaling down model LODs and making use of billboards if necessary, and dropping effects that aren't absolutely crucial, you should be able to reduce basically any graphics to any arbitrarily weak hardware. This would also mean a game download wouldn't need 130GiB on a machine that can only handle low LODs anyway. And the actual game state isn't that big either, usually. Basically a static version of nanite's dynamic LODs. And you can also use float16 or even more compact vertex formats like the 3 packed numbers in a 32 bit field. After all, low density meshes (LODs) probably don't need that much precision either.

I have actually been planning for a few years already to someday build an engine focused on running well on low-end hardware, but also supporting full quality on high end hardware. But never got around to do it because of job stress and all that.

JoeJ said:
It's not so simple i'm sure. If your minimum specs include low power handhelds, this means less gfx, less physics, less NPCs, smaller world, etc. So you simply can't make the same game you could make when targeting PS5 and up. If your minimum was PS5, and now you want a mobile version of your very successful game too, you need to reduce the game. Which is some work, so your cost is no longer 300M but 300M + X.

True, you can't have large amounts of LLM-driven NPCs or otherwise extremely complex mandatory game state simulations if you want to scale. But almost no game actually has compute-intensive core game logic of that sort, I think. And for almost all such games, it should be possible to amortise that logic over longer periods to make it run faster. But anyway, in such cases, it's not really a matter of graphics power. If essential core mechanics are extremely CPU-heavy and irreducible / can't be scaled down in any way, then that's fair. But then, the game could at least still run well on laptops etc., who usually have a good CPU, but simply not a powerful GPU. It would just have to run with reduced graphics.

Devices that simply cannot produce the necessary CPU compute power to keep up with core simulation, obviously cannot be targeted with the same game. Which means a mobile version could not share the same multiplayer as the high-end version, because the simulations they would perform would be incompatible. But it might also simply amount to tweaking some numbers to reduce the number of entities simultaneously in the world.

JoeJ said:
Now you may argue ‘i don't need fancy gfx and simulation - it's not what makes a game good’, and yes with this mindset your expectation holds. But the other guy will be sad his new RTX 5090 Dubai edition now needs external heating to get up to operation temperature, and no rays glitter on his screen, no beautiful AI girl faces are patched over ugly triangle meshes, and wheel suspension isn't simulated either. No immersion, he frowns. It seems everybody picks his own point from this scale for a reasonable expectation, which causes friction and dissatisfaction on all ends. Market fragmentation would fix this.

LOL. That's why I think a game should produce high end assets, and then statically bake them down into appropriate LODs for different machines. Theoretically, the machine could even bake the LODs based on a local benchmark, to meet the desired framerate etc. the player specifies. Then he has the full power to choose uglier but smoother, or even needlessly ugly, just for the fun of it, or to choose more fidelity at the cost of performance. Nobody would be artificially forced to play below what his hardware is capable of. But this would also be appropriate for handhelds. When it's on battery mode, it could switch to lower quality, and get more idle time at 60FPS, while on power mode, it could adjust the quality so that it barely reaches 60FPS.

So this adjustment can be made based on FPS constraints, battery lifetime / idle ratio constraints, and memory capacity constraints. And there is really just one slider, for the most part: more detail or less detail. Of course, different graphical aspects can be prioritised differently, so that maybe you scale down texture MIP levels before you remove bloom and ambient occlusion or something, or before you start downscaling render buffer resolutions, if the player prefers that.

cgrant said:
I do understand that what makes a ‘great game’ is HIGHLY subjective, but for each definitions of a ‘great game’ I guarantee polling will show that the user/player would take that over shiny new HW.

True. But recently, the hardware requirements trend had completely escalated. There are GPUs that cost $3000 and still can't run current AAA titles stutter-free. And AAA studios are starting to taunt players when they complain about performance, telling them to just upgrade their hardware, even when they already own unreasonably expensive hardware. Thus, by firmly establishing an 8GiB VRAM model as an explicit gaming rig, Valve did mark a big change in thought here. The Steam Machine is a de facto promise that it can run AAA games, even if not at max settings. Which means there are expectations on the player side that new AAA games will also run on that machine. Which creates some amount of pressure for AAA studios. And the un-upgradeable nature of the steam machine also means you can't just demand people upgrade their hardware. So if you want to sell a game to people who just bought a steam machine, you better make sure that you at least meet that hardware's capabilities. Which would also start to make studios maybe think about targeting even lower end devices.

cgrant said:
( HW will continuously improve over time)

But improvement per time is now perceptually less than the increasing cost of new HW.
At least that's how it feels to me. So instead expecting gamers to upgrade their HW frequently, i would rather like to see cheaper HW than more powerful HW.

To me this is an entirely new situation.

but for each definitions of a ‘great game’ I guarantee polling will show that the user/player would take that over shiny new HW.

Yes, but how was this in the 80s or 90s? I think it was different, and we wanted the increase in bits and colors the most.

Times have changed, however. So, can we just drop our dependency on faster HW?
Instead helping the HW industry to sell expensive GPUs and consoles, we might better freeze minimum specs at the current generation, focusing on software progress instead.

At least that's what i wish for. But they always come up with something… generating frames, AI this and that, ray and pixel reconstructions, texel shaders, or who knows what's next.
So it's not easy to escape their chokehold. But i tell you, going from 16 to 4096 colors was more awesome than going from 1 pixel to 16 halucinated ones. ;D

JoeJ said:
Times have changed, however. So, can we just drop our dependency on faster HW? Instead helping the HW industry to sell expensive GPUs and consoles, we might better freeze minimum specs at the current generation, focusing on software progress instead.

I'd freeze feature set at before they invented raytracing hardware and proprietary AI and fake frames and all that. And then you just have differently powerful implementations of that feature set. And you can set a baseline for what should be the bare minimum memory and compute power, to run on low settings. And what should be for normal, good looking graphics. I would define a generic 500€ laptop as being capable of playing 3D titles at low quality. And the steam deck for somewhere between low and normal, and steam machine at normal quality. And everything beyond that in power should be able to beef up its fidelity without limit. Mobiles are a bit tricky, since they have small screens and bad peripherals to begin with, and run on battery, and don't have that much storage usually, and also don't support many graphics API features (the support is quite heterogeneous and can't be easily grouped into supersets / tiers). That would need a thorough consideration before I could come up with a judgement for that. It should be needless to say that even phones and laptops should be able to run 2D games (and conventional GUI applications) without issue.

JoeJ said:
So it's not easy to escape their chokehold.

You just have to overcome your fear of missing out and commit to it. It's like switching to linux, haha. Or jumping into a pool. Once you did it, it's great.

RmbRT said:
I have been considering this option seriously because of my back problems.

Sounds like a good idea indeed. I have back pain too, down at the point where the spine meets the pelvis. It gets bad when the winter comes, like now. But this year it's much better than usual - so far at least. I hope it's because of some training practice i came up with. I stand on my knees, then fall back supporting upper body weight with my hands sidetly behind the back. Then i lift the pelvis upwards, hold and repeat. This stretches muscles in the thighs which are shortened from sitting, and experts say this causes the pain. I can feel the stretching above the knees. It also trains back muscles. I do this since a year and it really seems to help so far.

RmbRT said:
Epic really wanted to pull of Nanite and Lumen, so they did that. If now someone really wanted to pull off the opposite thing with an engine, trying to scale down assets, maybe reduce graphical precision where necessary, etc.

I think Nanites key problem is that it can not be used to scale down well. For many models the quality becomes pretty bad.
So it kinda fails on the true purpose of LOD, which is reduction, not an actual increase of detail.
Or at least this was my opinion. When i saw the first Nanite demo i was pretty shocked, because from this mindset i did not expect such insane detail is at all possible.

RmbRT said:
I have actually been planning for a few years already to someday build an engine focused on running well on low-end hardware, but also supporting full quality on high end hardware. But never got around to do it because of job stress and all that.

Maybe this is a hypothetical problem. There are some variables you did not mention:
You think of reducing high res models for low end. But then you have to create high res content, which is more costly than low res. And maybe it turns out the content you actually can do will not reach AAA levels anyway, so there is no need to have so much scaling in the engine either.
But also: The devices you consider low end now may be long gone when you finish your game. Though, since Moores Law is kinda dead, maybe this point looses its argument too.

RmbRT said:
The Steam Machine is a de facto promise that it can run AAA games, even if not at max settings. Which means there are expectations on the player side that new AAA games will also run on that machine. Which creates some amount of pressure for AAA studios.

It can also happen the Steam Box does not sell enough to be considered. Valves first attempt has failed, if you remember.

Personally i'm more optimistic this time, but i remain very curious about pricing…

JoeJ said:
I have back pain too

I got a hunchback and my entire upper back (from the neck down to the lower end of the ribcage) is extremely tense, probably a counter-reaction by the back muscles, to avoid further hunching over, as that would stretch the nerves in the spine too much. So it's a protective reflex. But the muscles are so tense, they squeeze shut some part of my spine. Only on days when I relax my back musculature, I have proper metabolic functions like digestive juices, stomach pulsing, etc.. On all other days, I'm just super tired and drained, and sleep doesn't help me recover. I once had a massage and the massage woman hurt her shoulder as she was massaging me with her elbow. She said she never saw anyone with such hardened back muscles. The way to get out of that extreme cramping/tension is to straighten the back out again, so that it is no longer overstretched from the hunching. But my frontside is so shortened that I can't really do that without issuing a lot of force. I mostly only manage to do that when lying down on the back without a pillow, and then do active relaxation exercises. So while it doesn't help with posture, lying in bed at least relieves the tension and the accompanying decline in metabolic function due to it pressing on my spine.

JoeJ said:
I think Nanites key problem is that it can not be used to scale down well. For many models the quality becomes pretty bad.

I think at least a static bake should have no problems reducing a 3D mesh's level of detail. After all, when you render, you can cluster together surface points and you can detect edges, surface gradients/slopes, and also triangle size. If there is a tight triangle cluster that is continuous in its surface & texture coords, it can be reduced automatically. And that doesn't have to be “perfect”, it just has to be good enough. A stochastic process is sufficient, and determinism could also be achieved via hash / PRNG / seeded noise. But Nanite cannot consider too much geometry at once on the fly, so it obviously can't reduce well. It's like expecting a real-time downsampling filter to be artifact-free when scaling down multiple magnitudes at once. There is always aliasing if your sample rate is too far from the data density. But a process that is not constrained to necessarily work in real time, doesn't have to care. And what you can also do is simply render the model (without multisampling), and for each pixel, remember which triangle in the model covered it. Then you can simply reconstruct a version of the model where all triangles that did not get a final pixel, are discarded. Of course it has to be a bit more complex since you have occlusion and all that. But I'm sure there is a simple trick that can get it to work. Maybe you repeat the process iteratively and eliminate all geometry that was visible in the last iteration, unless none is left. That way, occluded geometry is not falsely eliminated. So you only consider anything that was not occluded, but also eliminate all non-occluded geometry that did not end up with a final pixel. Maybe you need software rendering for that, idk. Or maybe some advanced atomics stuff during the pixel shader? Anyway, the basic algorithm seems fairly straightforward. You just eliminate all subpixel detail iteratively, and then reassemble the model from everything that was visible, or something. Should be doable within a few weeks or a month or two of research, probably. Definitely viable as a flagship feature of the engine.

JoeJ said:
You think of reducing high res models for low end. But then you have to create high res content, which is more costly than low res. And maybe it turns out the content you actually can do will not reach AAA levels anyway, so there is no need to have so much scaling in the engine either. But also: The devices you consider low end now may be long gone when you finish your game. Though, since Moores Law is kinda dead, maybe this point looses its argument too.

I don't think it's actually harder to make high resolution models than low resolution models. After all, in the editor, having a sphere with 1000 subdivisions is the same effort as one with 16 subdivisions. The same with deformation brushes. As long as you aren't adjusting every single vertex of the model by hand, vertex count doesn't really matter. And it's not about me. It's about having a tool that would allow AAA-scale projects to scale down their content. The tool can be built even if I am not doing AAA scale stuff myself. And yeah, I think we reached a point at which significant “progress” or “growth” in performance or capability isn't really worth much anymore. We got 24" screens with pixels so small we can't even see them with the naked eye, running at over a hundred frames per second. We reached the 4 ops/cycle at ≥4GHz CPU single-core performance level even on laptops. We got ≥16GiB of RAM, which is way more than any efficiently written software would ever reasonably use. We got more storage than a single person can reasonably fill up with manually created, meaningful content. Any meaningful realworld task imaginable could be solved by a computer faster than we can blink. At least anything that involves everyday things. Data transfer rates are crazy.

There is not really anything that's even an order of magnitude in capability away that would be paradigm shifting the way the leap from palettes to full RGB was, or that full HD graphics were, or that hardware accelerated rendering was. At least nothing a user or gamer would want or need. We can already render photorealistic scenes in real time at detail levels where you can't notice inaccuracies with your eyes. So anything beyond that would be so marginal in its improvement of the end result, that it's not worth it financially. I don't think we should force people into buying extremely expensive hardware, or ever buying better hardware than what exists now, ever again. We are at a point where requiring more hardware is mostly a sign of neglect on the developer's side. So I am simply making my own judgement call here and saying that current hardware is actually fast enough for everything I would ever want to achieve, and is also powerful enough to render everything you would reasonably want to render, even if it has to fall back on that LOD crutch. And 3D artists in 3D modeling magazines take hours to render a single scene, so there is always some niche space that will invest heavily into diminishing returns, and that's fine.

JoeJ said:
It can also happen the Steam Box does not sell enough to be considered. Valves first attempt has failed, if you remember. Personally i'm more optimistic this time, but i remain very curious about pricing…

Even if the steam box doesn't sell well, the tech stack has already been created. The SteamOS, the foveated VR streaming software, the windows emulation, the ARM/x86 emulation, etc. Someone down the line would be free to pick up the thing and attempt it again without reinvesting all that software-side engineering again.

Sounds i'm still lucky with my spine.

RmbRT said:
If there is a tight triangle cluster that is continuous in its surface & texture coords, it can be reduced automatically. And that doesn't have to be “perfect”, it just has to be good enough. A stochastic process is sufficient, and determinism could also be achieved via hash / PRNG / seeded noise. But Nanite cannot consider too much geometry at once on the fly, so it obviously can't reduce well. It's like expecting a real-time downsampling filter to be artifact-free when scaling down multiple magnitudes at once.

I would not expect to do better than Nanite. Although i can't tell how it compares to alternatives like Simplygon (which is very good), it seems good to me.
The reduction in Nanite is precomputed offline and considers the whole mesh. They use something close to the quadric error metric algorithm, which is greedy and uses a priority queue giving deterministic order.
At runtime Nanite only needs to select the current LOD, which would be negligible cost. But because GPUs suck with small triangles, their compute rasterizer adds to this cost ofc.

But as i said before, the problem is not the reduction of the geometry. It's the corruption of UV charts, triangle material attributes, etc., while doing so.
If your mesh is a rock with maybe only 6 UV charts, Nanite will give you a high quality reduction you could use for low end content.
But if your mesh is some sci fi environment with many small UV charts and material patches, your reduction will look broken from a closer distance.

Simplygon tackles this with features like material merging and generating new textures for discrete LOD levels.
Nanite does not have such features yet, afaik. But they could be added, since Nanite is technically still discrete LOD and not continuous.

The trivial way to deal with it is to protect edges on chart / material boundaries.
But ofc. this makes quality of geometry reduction worse and at some point prevents further reduction completely.

When you work on this, take a look at the Mesh Optimizer library on github. I use it to compute clusters and it's easy to use and just works. It can also do QEM reduction and boundary protection, and implements the compression ideas you have mentioned earlier.

I don't think it's actually harder to make high resolution models than low resolution models.

It is, believe me.
If you have a low poly model, and you want to change proportions, you can just drag individual vertices.
If you have a high poly model, well then you're fucked. You can try deformation cages, painting vertex selections, or spherical falloffs, etc. But nothing of this gives you precise control, while all of this makes it easier to ruin your model rather than fixing it.

This is why CAD modeling would be often much more efficient tool, also for games.
But CAD is very technical and not artist friendly.

RmbRT said:
It's about having a tool that would allow AAA-scale projects to scale down their content.

Simplygon is just that, and it already exists. It's even free to use for indies as a server service afaik. I've tried it years ago, and although this free version was limited in features, definitively worth a look.

There may be alternatives i don't know about, in case i sound like advertising.
What i really try to do is preventing you from going down the geometry processing rabbit hole.
You will not get good results in a view months. You will need this time only to try your ideas, learning they do not work and why, and how to eventually do better. Only after a path of failures you will end up doing the same things those mentioned libraries can do for you already now.

RmbRT said:
There is not really anything that's even an order of magnitude in capability away that would be paradigm shifting the way the leap from palettes to full RGB was, or that full HD graphics were, or that hardware accelerated rendering was. At least nothing a user or gamer would want or need.

Nah. There is still more stuff with have not done yet, than the bit of stuff we call the history of video games. They sky is the limit. We just need to go there… \:D/

(Reality: After 6 months of working only on the problem of making the ragdoll walk as fast as humans can, i'm still not there yet. : )

RmbRT said:
I don't think we should force people into buying extremely expensive hardware, or ever buying better hardware than what exists now, ever again.

I think the same. And i do not miss the times when the next gen was 200x faster.
I don't need even more performance any more. It's enough. Thanks.

But even if HW is stuck, this does not mean we are stuck too. Now its only on us to keep the ball of progress rolling.
I still expect and want progress from video games, and i feel responsible to deliver it.

RmbRT said:
Even if the steam box doesn't sell well, the tech stack has already been created. The SteamOS, the foveated VR streaming software, the windows emulation, the ARM/x86 emulation, etc. Someone down the line would be free to pick up the thing and attempt it again without reinvesting all that software-side engineering again.

Agreed as well. But you don't need to say thanks to Valve for all this. They take 30% from you, just for hosting some servers.
So they owe it to you, actually. And they should even sell their new Box at a loss to make it a great offer to gamers. ; )

JoeJ said:
The reduction in Nanite is precomputed offline and considers the whole mesh. They use something close to the quadric error metric algorithm, which is greedy and uses a priority queue giving deterministic order.

Ah ok, I didn't know that. But then why do people say that nanite saves you the hassle of caring about LODs? I thought it was about streaming un-LODed meshes. Ideally, you would get something that tries to retopologise stuff into maximum area coverage triangles.

JoeJ said:
This is why CAD modeling would be often much more efficient tool, also for games.

Yeah I had tried Maya or something for a short while back in my youth, and it was pretty complicated, but since it worked on ideal shapes rather than polygons, I assumed that blender would also offer similar modes. My other 3D modeling experience is the CoD4 and Source engine map editors, which is of course quite different.

JoeJ said:
But if your mesh is some sci fi environment with many small UV charts and material patches, your reduction will look broken from a closer distance.

That's true. Reducing a non-continuous surface sucks. I guess at that point, the original asset needs to be built with maximised continuity in mind. But artists always had to be aware of the technical limitations they were targeting, if they wanted to make something good. Like the palette and dithering hacks they did on CRT and all that stuff.

JoeJ said:
What i really try to do is preventing you from going down the geometry processing rabbit hole. You will not get good results in a view months. You will need this time only to try your ideas, learning they do not work and why, and how to eventually do better. Only after a path of failures you will end up doing the same things those mentioned libraries can do for you already now.

True. If I wanted to do flagship engine tier engineering, I would spend a few years on it. But something basic that goes 90%+ of the way, is definitely doable. And once you got something that works somehow, you can use it, at least in the cases where it works well. But since it seems that nobody is really using CAD anyway, it doesn't matter as much, I guess. I thought that was more or less the norm with 3D modeling. It's not really a priority for me anyway, at least not right now.

JoeJ said:
(Reality: After 6 months of working only on the problem of making the ragdoll walk as fast as humans can, i'm still not there yet. : )

Are you simulating muscles and tendons? I find it embarassing that modern ragdolls are still so pathetic. Look at the recent Skate game's ragdolls. That's a big title and when someone bails a trick, they just flop to the floor like a sack of … something. I don't know what. Because those ragdolls don't really seem to have mass or muscles or reflexes. They just slump over as if they were already dead, and as if they were made out of something very light, like foam or something. When you go for high quality graphics, the depicted things should also behave somewhat realistically. Like if you fall, the character should try to prevent landing on the face, and maybe try to roll to lessen the impact, or stretch out his hands, or try to adjust his balance by flailing. It can't be that hard for a AAA studio with massive funding to do at least a rudimentary version of it.

JoeJ said:
But even if HW is stuck, this does not mean we are stuck too. Now its only on us to keep the ball of progress rolling. I still expect and want progress from video games, and i feel responsible to deliver it.

Definitely. Especially since graphics have been milked so much and other parts of game design have been sorely neglected. Games got way too sterile with all the HUD indicators, yellow paint syndrome, and all the other handholding. There's still a lot of innovation left to do in the actual gameplay and overall atmospheric design etc.

JoeJ said:
Agreed as well. But you don't need to say thanks to Valve for all this. They take 30% from you, just for hosting some servers. So they owe it to you, actually. And they should even sell their new Box at a loss to make it a great offer to gamers. ; )

Yeah. Well, 30% is still a tolerable deal since they give so much visibility to games and all that, and the personalised suggestions and all. But if you wanted to, you could also distribute your game yourself and accept paypal or stripe payments. Steam doesn't forbid that, actually, I think.

RmbRT said:
But then why do people say that nanite saves you the hassle of caring about LODs?

Because people load their mesh into the preprocessing tool, and it spits out the Nanite data without any need to observe or tweaking parameters. It's fully automated.

Since you don't know, i'll tell you the interesting part of Nanite.
It's discrete LODs for per mesh as usual. But the LODs are divided into clusters of triangles.
The clusters form a hierarchy. A parent cluster at lod 5 may have 4 child clusters at lod 4. That's the data.

At runtime we need to select the level of detail we currently want. In the previous frame the lod 5 cluster was visible. But now we came closer and we want to render its 4 children instead.
Notice we do not even need to traverse a tree to find our lod. We can just check the selected clusters from the previous frame, deciding if detail should go up or down, or stay the same.

Now we arrive at the problem: We may now have a situation where one cluster has lod 4 but adjacent clusters have lod 5.
So the boundary edges do not match and we have a crack in the surface.
Previous methods proposed to stitch the crack at runtime, which requires mesh adjacency data to traverse the mesh, and it's very complicated and slow.
Because if this problem we avoided to do this at all, and preferred to select LOD only per mesh, which causes popping and works only on small models. A big model might want to have level 5 at the distance and level 1 nearby. But we could not do this using discrete LODs, so we had to render the whole model at level 1. Which is slow and not really a LOD solution at all.

Nanite solved this problem like so: The 4 child clusters from our parent cluster are merged to become a single cluster. Then it's remaining boundary edges are locked, and the reduction only affects the geometry inside. So the boundary has no cracks, but also it's edges have too much detail. We still want to reduce them, but luckily the boundary edges become internal edges as we merge the cluster with its neighbors to perform the next reduction step up the hierarchy.
To ensure edges do not remain locked through all levels, it is necessary to shift cluster boundaries across the levels, so an edge which is locked at level X isn't locked at X+1 as well, or at least not at level X+2. This adds some complexity, and we are forced to use a DAG instead a simple tree for the hierarchy. But that's really just an implementation detail.

Conclusion: Nanite solved a problem which was open for decades. The runtime cost is negligible, so you can use this on mobiles, and the quality is good.

If we notice that some UE5 games have performance problems, the reason is likely elsewhere. Maybe Lumen, or the still single threaded engine architecture, idk. But Nanite is a brilliant solution we should not ignore, they did not patent it and share their progress, and they do not deserve the disrespect.
I'm rarely impressed from hyped new tech. But in this case i am. This is exactly what gfx programming should be.

RmbRT said:
Yeah I had tried Maya or something for a short while back in my youth, and it was pretty complicated

There are some attempts to make it easier, but sadly Blender is not one of them. 3D modeling always was and still is extremely tedious.
I'll do what i can do minimize this kind of work. Modeling characters is fine, and maybe some guns or swords, cloth, dynamic objects.
Terrain can be procedural, but i'm not sure yet about architecture. I don't want to model modular building blocks and compositing them to make a scene. I want something mostly automated in the editor, but i'm afraid it would be years of work.
So i ignore this topic for now… : /

RmbRT said:
I guess at that point, the original asset needs to be built with maximised continuity in mind.

Yeah, the art of making good UV charts. It's just as much work as modeling the geometry itself. But it sucks much more.

RmbRT said:
Are you simulating muscles and tendons?

No. I use motorized ‘spherical’ or ‘ball and socket’ joints.
Some try to simulate individual muscles, bit it's nonsense imo. Better just simulate what all those muscles finally do, which is a single joint which can rotate the other body. But i may need to define max strength depending on axis and signs at some point to emulate muscles better.

I want to add a model of muscles as well, but only for visuals, to get skin deformations right. Unfortunately creating such model is a lot of work, more than the actual programming. : /

RmbRT said:
they just flop to the floor like a sack of … something.

That's because ‘ragdolls’ are dead bodies with no muscle force applied. You can add a bit of friction for rotation resistance to make a dead body more realistic, but it remains a lifeless corpse.

For a living character you need joint motors, which you can typically control by giving them acceleration.
But ofc. robotics is much harder than ragdolls.

RmbRT said:
It can't be that hard for a AAA studio with massive funding to do at least a rudimentary version of it.

Yeah, but they are too tied to their animation workflow it seems.
Still, i guess robotics is coming to games soon, in the form of AI driven libraries made by ‘AI experts’, if that's even a word.
I'm probably the only one who still works on this the traditional way.
Probably i won't be first, but i'll have more control, and i will truly understand how walking or running actually works.
I have learned those skills already when i was a toddler. But it did so like AI does. Trial and error, detecting and remembering patterns.
Then, as always when trying to convert assumptions into code, i have learned that i knew absolutely nothing about how balancing actually works for real. : )

RmbRT said:
Well, 30% is still a tolerable deal since they give so much visibility to games and all that

No, they don't do marketing for you. And the visibility you get is only on their own storefront, if you're lucky. They advertise themselves, for their own profit.
30% is way too much imo. 12% on EGS is fine.
You decide, you may say. But no. You don't. Steam has a clause preventing you from sellign your game elsewhere cheaper, so you can;t forward Epics advantage to customers, and so they never realize how they are robbed from their good gamer friend Gabe.
This should be illegal.

Bit it's not that i can't see all the good things Valve is doing… ; )

Ok, so you could easily use a nanite-like system even without deferred rendering or software rasterisation. It's simply a way of having different LOD regions for a “single” mesh. Which is reasonable.

JoeJ said:
Some try to simulate individual muscles, bit it's nonsense imo. Better just simulate what all those muscles finally do, which is a single joint which can rotate the other body. But i may need to define max strength depending on axis and signs at some point to emulate muscles better.

agreed. I recently saw some weird scene where they simulated the muscles in a horse, and it seemed quite silly to me, when there are much more glaring problems they need to address in their games instead.

JoeJ said:
Terrain can be procedural, but i'm not sure yet about architecture.

It is possible, via a mix of constructive geometry and individual fragments, maybe parameterised modules. But so far, I don't think many people have really given it a good shot yet. Roguelikes generate lots of 2D architecture, some even 3D, but so far, nobody put that much focus on it to make it really good. But architecture also has to fulfil a purpose in the real world, so believable architecture generation in games would have to be tweaked to fit the game's theme and lore etc.

JoeJ said:
Yeah, but they are too tied to their animation workflow it seems. Still, i guess robotics is coming to games soon, in the form of AI driven libraries made by ‘AI experts’, if that's even a word. I'm probably the only one who still works on this the traditional way.

Call it robotics, call it natural movement, I don't care. If you make a game with high quality graphics, then you also need to have high quality animations. But ragdolls are only suitable for corpses, not for living people who stumble or something. It would be better to have two or three good manual animations for falling and stumbling, than to just swap out the character with a corpse when he stumbles. I don't get how people would ever approve that idea, or look at it after it was implemented, and think it is somehow acceptable. And the funny thing is they had already added so many custom animations for all the skateboard tricks, so clearly adding 2-3 more animations is not an issue for them. But I guess that happens when you just slap UE5 onto something and then don't build any custom systems into it.

JoeJ said:
No, they don't do marketing for you. And the visibility you get is only on their own storefront, if you're lucky. They advertise themselves, for their own profit.

Yeah they don't market you, but the visibility to a huge audience on the storefront is worth a lot, especially for small projects.

JoeJ said:
You decide, you may say. But no. You don't. Steam has a clause preventing you from sellign your game elsewhere cheaper, so you can;t forward Epics advantage to customers, and so they never realize how they are robbed from their good gamer friend Gabe. This should be illegal.

Ah, I didn't know about that. But you can still sell it at the same price on your own, and then get a better cut for that. But realistically, nobody will buy from you directly then if it is the same price.

RmbRT said:
I recently saw some weird scene where they simulated the muscles in a horse, and it seemed quite silly to me, when there are much more glaring problems they need to address in their games instead.

I saw this in the Witcher 4 showcase recently. Which is just for visual purposes. Imo this is not silly but absolutely necessary. However, for humans, not for horses, please! On a horse i would not spot anatomical incorrectness, but on humans i do. And its terrible. When game characters diverge from the Tpose they were modeled in, they look like abominations. It's silly to scan Keanu in glory detail, playing back his captured motion in a path traced game supposed to look real, but then his proportions look like drawn from a 5 year old which has no talent. Character animation became the biggest flaw in game art, and they are really late with trying to improve, imo.

However, this horse looked like the tech they use for offline animations. There was a company, Ziva iirc, and they worked on such simulations and tools. Used in Hollywood movies, and pretty good. But then Unity bought the company for reasons nobody comprehends, just to close it soon after that.
They model individual muscles as meshes, make a volumetric tetrahedrilization (this time i'm too lazy to google correct spelling : ), and do some kind of soft body simulation on this data. But that's way too expensive for realtime, so Unreal surely does it a bit differently.

Another method showing up in recent games is using machine learning, which is basically ‘i have no clue and won't figure it out, so let's try to machine learn it and claim it's cheap’. I assume this also is expensive.

My idea is to model muscles with a simple line between two bones. Then i revolute a simple spline around the line to get some cylindrical shape of varying thickness, which can stretch and compress depending on line length under motion. I'll need a few such lines to model a single muscle, but it's a cheap primitive and does not need any simulation at all. A patch of skin then precomputes a set of musclues to check for collisions for displacement. I already have a method for cheap skin deformation which can do sliding and volume preservation. Adding some muscle collisions should add the missing details.
But i'm not sure yet if i indeed get away with simple lines and no handling of muscle - muscle collisions. I'll know only after creating an entire leg for testing. And all this is down at the bottom of my todo list.

RmbRT said:
but so far, nobody put that much focus on it to make it really good.

I think there are more good examples than we are aware of. Assassins Creed or Star Citizen generate most of their architecture procedurally, which is not obvious because results are so good.
Or the indie game Townscaper, awesome. There are YT videos about how this works.
There surely is much more.

RmbRT said:
Call it robotics, call it natural movement, I don't care.

Well, we need to agree on some terms for discussion.
I choose ‘robotics’ for the case where we use traditional rigid body simulation, but with motorized joints so we can control their motion.
In robotics they also used no animation data but generate it procedurally. (Although, this has recently changed assuming many robotics startups now use AI trained on animation data)

So that's a good term i think. And it's really the same work they do at Boston Dynamics, just that we don't need to care about motor and sensor latencies. But the Controllers are generally the same.
I wish there would be a different word, because i now associate 'robotics' with AI driven machines meant to replace our workforce, but that's what it is.

RmbRT said:
It would be better to have two or three good manual animations for falling and stumbling, than to just swap out the character with a corpse when he stumbles.

Strongly disagree. Following this, you need 2-3 variations of animations for absolutely everything a character can do, which in turn means your characters can't do anything at all until an army of artists has created, or scanned and cleaned up all those animations, which is exactly why GTA6 costs a billion dollars, and why guys like you and me can only play but not make such a game.

No, using ragdolls for death animations is the right method. But you need to setup joints to behave naturally regarding limits and friction. You do this only once, and then all your characters fall to death realistically respecting current velocities and any environment. And picking up corpses to throw them around is still fun for players.
A common problem here is that physics engines may not have standard joints which are good to model human joint limits, and also that artists may lack the background, references and tools to setup such things properly. It's no wonder some devs decide static death animations fuses better to the rest of their game. But they are wrong. : )

RmbRT said:
But you can still sell it at the same price on your own, and then get a better cut for that. But realistically, nobody will buy from you directly then if it is the same price.

It's a typical dilemma.
If you sell on your own beside Steam, Steam sales will be so much more it's not worth the effort.
If you sell only on your own, you're afraid to be completely ignored. Even if Minecraft proofed it can work.

Well, luckily i do not need to worry yet… : )

JoeJ said:
No, using ragdolls for death animations is the right method.

Yes, but in this case it's not a death animation. It's literally a skater losing balance or tripping up at an obstacle. Sometimes at not that much speed. No arms flailing in an attempt to keep balance, no attempts to not face plant, just numbly sagging onto the floor or into a wall, face-first, because he tripped over a ledge. And then twitching on the floor because the corpse ragdoll simulation is unstable. And then standing back up.

JoeJ said:
I wish there would be a different word, because i now associate 'robotics' with AI driven machines meant to replace our workforce, but that's what it is.

That's why I would call it natural movement. It originates from humans, not from robots. Although the engineering discipline originates in robots, I guess.

JoeJ said:
There surely is much more.

Yeah. I think any talented individual who actually is passionate about it, can pull it off. I think the bad reputation for being hard or unsovled mostly comes from people who aren't passionate/inspired about it. Same with nanite's LOD approach. Only someone who was really passionate about making better LOD transitions could have come up with it, but you don't have to be a genius to come up with it. But most people simply didn't have the drive and passion for it that is required to spend weeks, months, or years on it. Same with architecture generation. I think this is also a big problem with big teams that get delegated top-down: in the end, it has to be the engineer who works on a specific thing who has to be really inspired about that task to make it cutting-edge. But if everything is top-down, and does not allow for such experiments, then a structure like that will not produce such innovations. In small teams, where the human factor and communication are much stronger, I think it is actually easier for inspired individuals to be given the opportunity to follow up on that inspiration. Of course, that's just the tendency, not an absolute.

JoeJ said:
I'll need a few such lines to model a single muscle, but it's a cheap primitive and does not need any simulation at all.

Yeah, the muscle's behaviour is not the cause, but the effect of the actual animation. Which is easy.

RmbRT said:
Yes, but in this case it's not a death animation. It's literally a skater losing balance or tripping up at an obstacle.

Oh, i should have known there is no death in Skater games. : ) But hey - why not? A skater game through a labyrinth of deadly traps would be quite nice. Skate Or Die 2 - but now for real.

Reminds me on Uncharted 4. In this game animated characters swing on ropes between cliffs. Looks totally ridiculous, but still impressive as well.

RmbRT said:
That's why I would call it natural movement. It originates from humans, not from robots.

Hmmm… you're right. I'm actually trying to reproduce what i can do, not what Boston Dynamics does.
‘Natural movement' is actually too close to Natural Motion, the first company working on bringing this to games. But maybe ‘locomotion simulation’ is already better than robotics.

RmbRT said:
I think the bad reputation for being hard or unsovled mostly comes from people who aren't passionate/inspired about it.

Or the advice comes from people who worked on the field, know how much time it takes and want to stop those - who may not be passionate enough - from wasting their time on the wrong subject.
That's what i do at least. I warn about everything i know, so when you decide to do it anyway, your passion level is sufficient. :D

RmbRT said:
Only someone who was really passionate about making better LOD transitions could have come up with it, but you don't have to be a genius to come up with it.

Whenever i came up with something, it always required a long path of failures to get there. So yeah, maybe it's just trial and error.

RmbRT said:
I think this is also a big problem with big teams that get delegated top-down: in the end, it has to be the engineer who works on a specific thing who has to be really inspired about that task to make it cutting-edge. But if everything is top-down, and does not allow for such experiments, then a structure like that will not produce such innovations.

It's a system of controlled production then, where innovation is not the goal, but just the product. It's also a form of oppression, which always finds its way in any civilization and society, i'm afraid. And maybe every former society was believing to be free regardless, like we do as well.

Anyway, today i've had an interesting idea about the content generation problem. Let's say we start with a procedural world, after working on methods to create terrain and architecture in whatever way. So we all have this procedural boredom available.

Now the question: If we want to design a level, what works better? Starting from scratch with some idea in mind?
Or looking at the boredom, become inspired from it, and then modifying it so we turn it into a level?

I think the latter might work very well, especially if we are already happy with the initial boredom result.

RmbRT said:
Yeah, the muscle's behaviour is not the cause, but the effect of the actual animation. Which is easy.

That's how i think of it for now, and it's enough to verify for anatomical correctness. Which is my primary goal.

But after that point i need to turn it around. Muscles tense up before the consequential motion happens, so we need to calculate this. Which i can do using data of the ragdoll controller.

And if this works as well, it will look like a painting from Frank Fazetta, showing muscle heroes slaying dragons in epic settings. Which is what we want. \:D/

JoeJ said:
Now the question: If we want to design a level, what works better? Starting from scratch with some idea in mind? Or looking at the boredom, become inspired from it, and then modifying it so we turn it into a level?

I think the latter might work very well, especially if we are already happy with the initial boredom result.

To figure out what the generator should generate, you need to already have acquired a taste through manual creation or at least active imagination. First, you try to replicate your style and taste. Then you get to the point when the generated thing just needs to be tweaked. That would be the start. And then you figure out what kind of changes you make to it, and try to add that kind of thing to the generator. Because from then on, it's a matter of large-scale intent that adjusts the fine-scale art here and there, probably mostly reorganising or slightly tweaking aspects for some practical purposes or something. So it may just be two ways of looking at the same process: the generator represents the intent behind manual design, and the manual design informs the generator code. And in the end, you might end up at a fully codified version of your manual process, or something that is close enough to at least serve as filler content. But all that effort really only pays off at scale. The further you go along that path, the more the returns diminish, so it would mostly be a matter of pragmatism to decide where to stop investing into the generator.

JoeJ said:
But after that point i need to turn it around. Muscles tense up before the consequential motion happens, so we need to calculate this. Which i can do using data of the ragdoll controller.

But do you not also know ahead of time the animation you will take? Or at least the animation that is planned to happen? After all, all action comes from some impetus, such as human input, or the consequence of it, or the consequence of simulation. In theory, you could simulate a bit ahead, or anticipate at least animations a bit ahead, and make that affect the muscles also. Which basically just makes it into a consequence from the future, instead of a cause. And you might not even have to actually simulate or anticipate much, since usually, the starting state and starting action of an anticipated motion is usually known a priori. So it might not even require any extra computation, just extra knowledge.

JoeJ said:
And if this works as well, it will look like a painting from Frank Fazetta, showing muscle heroes slaying dragons in epic settings. Which is what we want. \:D/

Wow, how come I never heard of him? Do you know what his connection to Jean Giraud / Moebius is? I'm interested in the lineage of modern art and entertainment. According to what I learned, much of modern sci fi movies and comics and even manga and anime can be traced back directly to Moebius. But I see that he was born 18 years prior to Jean Giraud, and already drew something that would be considered the new style, in at least 1953, which is before Moebius even started working in the comics industry (the cover page here was made by him and came out in 1953, according to the Wikipedia article):

I'm no scholar on that kind of stuff, though. This guy was already nuts even before Moebius could have been able to leave an impact. Do you know more about that kind of stuff? I've been wary of how Moebius influenced so much of pop culture when he had all this occult and psychedelic drug influence.

RmbRT said:
And in the end, you might end up at a fully codified version of your manual process, or something that is close enough to at least serve as filler content.

It depends on the game. For example, for the puzzle game i have made, procedural levels would be completely impossible. For Super Mario it would work, but the levels would be boring. For Quake it would work better, if you make sure combat dominates over finding switches.

For some open world game, we could grow meaningful villages, cities and economy over the landscape, like in Sim City.
Which i would classify as filler content or procedural boredom. Then we can manually refine the layout and adding quests.
But such environment will never be as good as human made Mario or Quake levels regarding gameplay.
Really all modern open world games are like that. They have no level design at all, and it's not expected either. But imo that's very bad.

Now i assume the generator can be tuned to make environments which serve gameplay too, especially if we do not attempt to create realistic scenes. But still, for key places, strong manual modifications are needed. They should still merge with the filler stuff surrounding them, but we want to do big changes very quickly, so we can do trial and error / experimentation.

The big question now is: How do we define the geometry, how do we create and edit? We want CSG operations to add doors at any place, we want to draw walls extruded from simple lines, etc.
CAD can do all this, but that's years of work i'm afraid.
SDF modeling like in Dreams can do it too, and i already have this for my editor. But it's imperfect and lacks precision, and it takes much more storage and ram than CAD models.

So i'm pretty clueless on this subject. Likely i can't choose my art style freely, but i have to use something which eases generation first.

RmbRT said:
But do you not also know ahead of time the animation you will take?

Yes. For example, when walking i know where the next footstep is, and how long it takes to get there. So i always know enough and muscle animation will be fully automatic.

RmbRT said:
Wow, how come I never heard of him? Do you know what his connection to Jean Giraud / Moebius is?

I think Frazetta has contributed a lot to the defintion of ‘modern’ fantasy art, with people like Lois Royo coming later afaik. But i'm no expert.

Moebius, Giraud were comic artists, but covered similar topics ranging from fantasy to sci fi.

Then there are sci fi artists like Roger Dean, Syd Mead, Joen Berkey, etc.

Most of it comes from my favorite decade, the 70's, and earlier.

This is a great resource for inspiration: https://70sscifiart.tumblr.com Sadly i never found such blog about fantasy art.

What all of these guys have in common: They are all envy on another guy, which did not become very famous because he has only drawn erotic comics. But he's the best of them all. Milo Manara. My career as comics artist ended the day when i saw his work during art school. I knew i would never get there, and nobody else did either, no matter at which century you look.
I have not forgotten what he has done to me. And since then i hope i maybe can get there with the help of computers… : )

I haven't thought about level generation, especially interiors, that much yet. I only thought about the macroscopic generation of landscapes and town placement, etc., including gameplay/game simulation-focused macroscopic generation. That kind of design is mostly focused on achieving purpose while making it look natural, while interior design is quite different, with focus on utility, beauty, convenience, etc., and these concerns have completely different metrics compared to terrain generation, town/infrastructure placement, and town layout.

JoeJ said:
Really all modern open world games are like that. They have no level design at all, and it's not expected either. But imo that's very bad.

If you just design something that looks like a town, it will look good, but will suck for gameplay. You need to know exactly how town layout affects gameplay, and what gameplay effect you want to get from your town's layout, its population, infrastructure, etc.. I don't think it actually needs unrealistic levels to have good design. Maybe statistically implausible, but not unrealistic looking. You need to know how connectivity via roads factors into gameplay, and whether you want to create places where you have to take detour, where to place points of interest, and how the line of sight should be for gameplay reasons. There are real cities that have just endless straight roads in a grid, where you would have too much line of sight to get fun close quarters combat out of it. Or where the road layout wouldn't be fun for racing. But there are just as real cities where you have kind of crooked and winding roads and you rarely have far vision down some road. The architecture and shape of houses can also make a huge difference for gameplay, in terms of how much cover from fire, and from sight, they offer.

———————————————————

Something that's more on-topic again: apparently only 30% of steam users have more powerful hardware than the Steam Machine. So claiming it is insufficient to play new games means that new games are only made for 30% of the steam audience. Which is kind of weird. But that also means that indies that target lower HW requirements, get to target the other 70% that do not have access to all the new games that are coming out. Granted, you can't target that 70% fully unless you target the lowest common denominator which would be at 256MiB or 512MiB of VRAM, I forgot. But that's still quite the sizeable percentage, and given the 200 million steam users or what it was, those 10% or something are still a huge audience that doesn't get access to any of the new games out there.