by Darkcrafter » Sun Oct 13, 2019 3:07 pm
Rachael wrote:I think this has been brought up before, and the answer was no. Mostly because of the insane amount of processing power this would require.
Yes, it's been there around zscript board, but now it's here officialy.
Nash wrote:Even modern game engines like Unreal Engine 4 don't do full mesh collision - you have to construct a separate, (very) low poly collision mesh. Assuming someone implements the work needed to make this work (which has already been explained - not trivial at all because Doom's movement code is too primitive), it would most likely not work automatically and the content author has to do the collision meshes themselves.
Given the current limitations of the [GZ]Doom engine, the best option you have today (one that doesn't explode the processing cost from too many actors, and works the nicest within the engine's limitations) is to construct invisible 3D floors to act as your "collision mesh".
The process of making those meshes is not a thing an artist would afraid of, but this movement code doom has. It really can be hard for an average hardware, but I hope this will be the problem of past soon, as there is finally competition on the cpu market again. By the way it's not about UE4 but seems like Unity supports not just low poly collision meshes, but very hi-res ones. Another problem is that the collision detection alghorithm sometimes fails, for instance it might close holes that are supposed to be open like caves:
https://youtu.be/46hSbkTuHmc?t=208
I'm gonna create a special map with thousands of such collision boxes and see how it affects the performance on a 1st gen ryzen pc from 2017 and amd athlon from 2006 and make a report on it, but now with 2160 thinkers, the think time is just 0.94ms (ryzen). Maybe having that much of actors is not such a big issue for a modern system?
The more I map the more it seems to me that there is no such thing like a "best option". There are multiple scenarios that require different approaches, for an instance there is a lot of hassle with configuring them and if there is a sloped terrain one have to deal with drawing complicated linedef patterns whereas a simple decorate based actor that hovers above it in a desired position solves the problem effectively, there is no need to redraw the map geometry that is already so complex. Configuring a 3d floor to become sloped is also another problem, what if your 3d model is curvy and it would a huge pain in somewhere to create all these sectors to approximately describe a surface, then you can't move, scale and rotate your geometry without breaking it.
[quote="Rachael"]I think this has been brought up before, and the answer was no. Mostly because of the insane amount of processing power this would require.[/quote]
Yes, it's been there around zscript board, but now it's here officialy.
[quote="Nash"]Even modern game engines like Unreal Engine 4 don't do full mesh collision - you have to construct a separate, (very) low poly collision mesh. Assuming someone implements the work needed to make this work (which has already been explained - not trivial at all because Doom's movement code is too primitive), it would most likely not work automatically and the content author has to do the collision meshes themselves.
Given the current limitations of the [GZ]Doom engine, the best option you have today (one that doesn't explode the processing cost from too many actors, and works the nicest within the engine's limitations) is to construct invisible 3D floors to act as your "collision mesh".[/quote]
The process of making those meshes is not a thing an artist would afraid of, but this movement code doom has. It really can be hard for an average hardware, but I hope this will be the problem of past soon, as there is finally competition on the cpu market again. By the way it's not about UE4 but seems like Unity supports not just low poly collision meshes, but very hi-res ones. Another problem is that the collision detection alghorithm sometimes fails, for instance it might close holes that are supposed to be open like caves: https://youtu.be/46hSbkTuHmc?t=208
I'm gonna create a special map with thousands of such collision boxes and see how it affects the performance on a 1st gen ryzen pc from 2017 and amd athlon from 2006 and make a report on it, but now with 2160 thinkers, the think time is just 0.94ms (ryzen). Maybe having that much of actors is not such a big issue for a modern system?
The more I map the more it seems to me that there is no such thing like a "best option". There are multiple scenarios that require different approaches, for an instance there is a lot of hassle with configuring them and if there is a sloped terrain one have to deal with drawing complicated linedef patterns whereas a simple decorate based actor that hovers above it in a desired position solves the problem effectively, there is no need to redraw the map geometry that is already so complex. Configuring a 3d floor to become sloped is also another problem, what if your 3d model is curvy and it would a huge pain in somewhere to create all these sectors to approximately describe a surface, then you can't move, scale and rotate your geometry without breaking it.