PC Developer Discussions: Alpha 17

Developer Discussions: Alpha 17

  • Newly Updated

    Votes: 1 100.0%
  • Check out the newest reveals by Madmole

    Votes: 0 0.0%
  • Over 100 new perk books with set collecting and bonuses

    Votes: 0 0.0%

  • Total voters
    1
Status
Not open for further replies.
If you remove anything it should increase performance. You might want to take ferals out of the spawn lists, if memory serves they're a bit heavy on system resources.
Ferals must stay, trees gonna die. :smile-new:

I thought to remove all the trees except the pine forest to increase perfomance.

 
Ferals must stay, trees gonna die. :smile-new: I thought to remove all the trees except the pine forest to increase perfomance.
You could try lowering the spawn rate instead of removing them entirely, that way you can still collect some wood no matter where you are.

 
You could try lowering the spawn rate instead of removing them entirely, that way you can still collect some wood no matter where you are.
Just need to wait for release of A17, to decide the fate of my trees.

Less wood sources could add a bit of a challenge to the early game.

 
If I remove all trees in snow biome, it will increase performance even more?
In the snow biome.. yep!

You would need to tweak the other biomes as well to get similar results.

 
Last edited by a moderator:
I was under the impression from Roland's thread on A17 that the quest givers are the traders primarily, so the premise is "being at a trader." Which yeah, you are vulnerable at a trader, but also you can't build within so many blocks of a trading post so it's doubtful that you'll see constructions built "around" quest givers is kind of what I'm trying to say.
Ok, but traders are already surrounded by walls behind doors you can close, so the premise of the poster I was answering to seems to be something else. Make sure no one is inside the compound, make sure the compound door and the door to the room are closed (so you hear the doors opening) and the trader should be relatively safe to talk to.

 
That already happens automatically with unity, technically it's the colliders attached to the physics objects that are the problem but without them everything would fall through the floor.
Removing colliders from objects and making them static far from the player would have some odd consequences, I'd be able to shoot a rocket launcher at a pile of corpses and the projectile would just pass through them. Activating them all when a rocket got close enough to them would give the frame-rate a crippling stutter for a few frames and probably send bodies flying through the air for miles, the physics engine would read the activated colliders as new collisions and behave appropriately.

Nice idea but unworkable.
Physics engines are great for things like vehicles, and realism overkill, but IMO I don't think anything besides the vehicles really need to use any kind of complex physics engine. TFP could write a lower level physics handler for things like gibs, and whatnot, and run them both. I don't know anything about how unity works, and what freedoms the coders have though...

 
Will the zombies at least slightly turn their heads towards the player when they are above or below the zombie? Now zombies look only in front of themselves and do not turn their heads at all
It is on my list. Not sure that will make A17.

Will the zombie have an animation of the face (movement of the jaws and eyes)?
All this can add fear to the game, is not it. Now zombies are just dolls that are not like people and therefore do not inspire fear to players (
Not planned as far as I know.

 
That assumes that quests will only ever be given by traders which would be a shame and a wasted opportunity.

What about random encounters with other survivors out on the road? There was talk of bandits demanding bribes from you, if they get the drop on you then you're not going to have time to build a wall around the entire gang. What happens if you're having a conversation with a settlement's guards outside their walls, are you going to be able to build that close to their base?

Forcing a player to look at the character they're talking to is fine in a single player game but it's very unrealistic from an immersion perspective and a liability in a pvp environment.

 
Physics engines are great for things like vehicles, and realism overkill, but IMO I don't think anything besides the vehicles really need to use any kind of complex physics engine. TFP could write a lower level physics handler for things like gibs, and whatnot, and run them both. I don't know anything about how unity works, and what freedoms the coders have though...
You can write your own physics from the ground up or integrate another physics library of your choice. That's a hell of a lot of work though and if you intend to integrate it into unity's built-in physics engine then there's little point, and quite a few disadvantages, in adding a second set of physics.

Many years ago I coded accurate particle physics into unity for fun, I can see why physics engines cheat quite a bit because accurate physics is incredibly hard on the system resources.

 
Last edited by a moderator:
That sounds like the same problem. The root cause of it is likely to do with the utterly crazy way modern processors deal with floating point numbers. In just about everything else in computing things are deterministic, not with floating point arithmetic. Some genius decided early on that modern processors should use a floating point instead of a fixed point, mainly for the gain in processing speed. This has been the chagrin of many developers of both hardware and software over the years... myself included. The upshot of this is that if you try to calculate the same number twice it's pretty unlikely that you'll receive the exact same result, the more calculations required to get the answer the less likely the answer is to correlate.
Floating point is generally about the same speed as integer math on similar operations like 2 + 2. It was made for the extreme ranges of numbers you can use, but at a loss of precision, since both are typically 32 bit values, but floats need some of those bit for the exponent, thus reducing the significand's range of values.

https://en.wikipedia.org/wiki/Floating_point

"is arithmetic using formulaic representation of real numbers as an approximation so as to support a trade-off between range and precision. For this reason, floating-point computation is often found in systems which include very small and very large real numbers, which require fast processing times. A number is, in general, represented approximately to a fixed number of significant digits (the significand) and scaled using an exponent in some fixed base"

 
Floating point is generally about the same speed as integer math on similar operations like 2 + 2. It was made for the extreme ranges of numbers you can use, but at a loss of precision, since both are typically 32 bit values, but floats need some of those bit for the exponent, thus reducing the significand's range of values.
https://en.wikipedia.org/wiki/Floating_point

"is arithmetic using formulaic representation of real numbers as an approximation so as to support a trade-off between range and precision. For this reason, floating-point computation is often found in systems which include very small and very large real numbers, which require fast processing times. A number is, in general, represented approximately to a fixed number of significant digits (the significand) and scaled using an exponent in some fixed base"
Many of us would have preferred fixed-point arithmetic despite the slight reduction in speed. Over the years floating-point has caused more problems than it's solved. If it wasn't for the fact that such calculations are built in to the processor I would have written my own fixed-point library and never looked back.

 
Last edited by a moderator:
Physics engines are great for things like vehicles, and realism overkill, but IMO I don't think anything besides the vehicles really need to use any kind of complex physics engine. TFP could write a lower level physics handler for things like gibs, and whatnot, and run them both. I don't know anything about how unity works, and what freedoms the coders have though...
Vehicles interacting with the world and entities requires those to have colliders and sometimes rigid bodies. Ragdolls also use physics.

Gibs, explosions and such are typically particle effects and do not use the physics system.

 
Vehicles interacting with the world and entities requires those to have colliders and sometimes rigid bodies. Ragdolls also use physics.
Gibs, explosions and such are typically particle effects and do not use the physics system.
So se could have limbs ripped of instead of just exploding?

 
You can write your own physics from the ground up or integrate another physics library of your choice. That's a hell of a lot of work though and if you intend to integrate it into unity's built-in physics engine then there's little point, and quite a few disadvantages, in adding a second set of physics.
Many years ago I coded accurate particle physics into unity for fun, I can see why physics engines cheat quite a bit because accurate physics is incredibly hard on the system resources.
I wouldn't suggest trying to integrate, but run along side, and apply specifically to objects not using the built in physics. Writing your own physics from the ground up isn't so bad if you've done it before, and you are going for the bare minimum, such as bouncing off anything, but only really rolling and sliding on the ground rather than applying full physics to every collision. Bounces don't even have to be completely accurate. Bounding boxes can just be rectangles rather than having a shape.

That said, dead bodies ragdolling would still require the more advanced physics engine. I've recently written such physics code for Quake gibs using its limited collision types and limited angle handling, and it runs so well that I don't ever remove the gibs at any point. And at this stage in the development, everything gibs when it dies, so there are a LOT of gibs. You can also kick them around for an unlimited amount of time. The real key to the massive number of gibs is that I take them out of their linked list when not near a player, and not moving, so that when I calculate physics, they are completely ignored. The player or any other moving object can do radius checks to re-add gibs to their linked list.

Does unity have a function to trace into models and detect a collision without being forced to use a collision object to detect such a thing? If so, that would be required to avoid using the expensive collision objects.

- - - Updated - - -

So se could have limbs ripped of instead of just exploding?
That would require them to use something for limbs other than particles. Unless someone gets creative.

 
Does unity have a function to trace into models and detect a collision without being forced to use a collision object to detect such a thing? If so, that would be required to avoid using the expensive collision objects.
Not built-in, you'd essentially have to write your own collider system based on mesh limits to do it and that would get computationally expensive on a complex mesh. It should be relatively simple to apply those interactions to the unity colliders as long as you know the impact point and speed.

Update: I was wrong, here's some code that does it straight from the vertex data but its still computationally expensive on a complex mesh.

https://forum.unity.com/threads/raycast-without-colliders.14378/

 
Last edited by a moderator:
Many of us would have preferred fixed-point arithmetic despite the slight reduction in speed. Over the years floating-point has caused more problems than it's solved. If it wasn't for the fact that such calculations are built in to the processor I would have written my own fixed-point library and never looked back.
I'd rather have the float range of values for the world, not a +/- 2 million range that I have to reduce to get x bits of fraction. If you want precision, you go with double, with its 53 bits of significand precision, which I have seen some people wishing Unity used and someday it probably will as computers reach the everything is 64 bits and so fast and with so much RAM, that we don't care anymore.

 
Status
Not open for further replies.
Back
Top