As far as I know, the differences between DX and OGL are fairly minimal (despite what you see when they release a new gfx card they are trying to sell you). You can do pretty much anything in both and the transparency issues are because of the deferred rendering system design, which is UWE-made and could be constructed using either API.
He was implying that those mechanics will remain in NS2 to demo its capabilities.
Why? Does he honestly believe that other engines aren't capable of something similar to the power node mechanic? The first infestation prototype was demoed in Source FFS.
The first infestation prototype was done in Max's engine, not on Source.
i would love to see HITREG and PERFORMANCE fixed
and then concentrate on everything else.
PM me videos of hitreg issues with net_stats enabled, if you are able to, and i will report it.
If it gets fixed and makes it into the changelog i'll be sure your name is included as a thanks for solving this for everyone!
Currently we don't have any hitreg related issues reported/open ... we have a suspicion but nothing captured or able to be reproduced, and would love it if someone as yourself who experiences it, could capture it in 60fps 1080p video for us to examine.
You can also email me ironhorse@unknownworlds.com
Thanks.
Most people won't even be able to play with these kinds of settings/performance and you want people to record with them?
Maybe that's the reason why no "evidence" has been found yet.. Can we at least agree that server performance seems to impact hitreg and as such there are bound to be hitreg issues no matter what? At least as long as server performance stays as wonky as it is right now..
But nobody can tell me that there are "no hitreg" problems when Skulks, that should die to 12 LMG bullets, regularly need double the amount of that (unless they are running straight at the Marine).
le sigh. the reason the skulks take more than 12 bullets to kill are because they are small and move well. you'd be very luck / fortunate to be able the cleanly land 12 in a row on a skulk. really, its hard, those bastards are small and can change direction.
my feeling is, if anything, it will be some hitbox/lag compensation problem that some players will 'feel' more than others. I'm not the best NS2 player by far, but I'm good enough to know that when I die and feel like my bullets didn't hit it is most likely that I didn't aim good enough.
Hey max!
I noticed on your twitter feed you mentioned Screen Space Reflections (judging that these are just cube maps). Do you plan on implementing some sort of hybrid solution between the two as seen in the most recent crytek games?
Ex...
Depending upon angle of inflection use SSR... otherwise blend to cube map.
@ironhorse I think this issue is actually multifaceted.
The damage numbers which pop up are counter-intuitive as is the hit detection graphic (green blood spurt) - Your client can show you hitting an alien who is actually taking no damage in my personal experience, so you feel like you are hitting a Skulk but the server disagrees so it takes no damage. During this moment it causes your client to pop up the damage counter; which calculates you have done enough damage to kill the Skulk who has now proceeded to rip your face off.
The damage numbers that pop up are 'pure' not taking account of attack type and armour values, example - The marine rifle deals normal damage, a skulk with carapace has 70hp and 30 armour. Each point of armour takes 2dmg to remove vs normal attacks, so a base skulk has 90 effective health points and carapace skulk has 130. You shoot a carapace skulk, you do 110 damage, you know it has 70hp and 30 armour, it lives - this is counter -intuitive as you have done more damage than its HP+Armour values add up too.
This all adds up including the lag compression and probably frame rate issues to make the games hit registry feel VERY very sloppy. Sometimes you'll feel like your missing but be blowing Skulks into next week, other times you were sure you were on target and get beaten down again and again.
On top of this, I think most people can't handle hit "boxes" that are spot on with the model. They are used to have real "boxes" as hit zones. Like they are in older games. They aren't used to shots going between two legs are counted as miss.
_Necro_ I've not had chance to actually explore the hit boxes in NS2 properly yet; but that could indeed be a very good point. But on the flip side, I want kill a skulk by shooting its tail
The game has a 30 tick rate, which is a pretty big bottleneck, especially late game when the engine cannot maintain that rate with conventional hardware.
Will writing some application layer between the lua and engine fix this? Maybe, but I imagine it's just the net code needing a more efficient design, it seems to lock up like a traffic jam when it's busy.
(30 ticks with less than 30 people. It's been done for over a decade with the normal results we've come to expect, but not yet in this game. )
@Rippsy: If you hit the tail, it will count as hit. But if you are just slightly off, it will not. Most people are use to hitboxes that are bigger than the model.
@Kalabalana: I have no problem finding servers that can hold the tick rate of 30 even in end game. Given you don't play on servers that are > 18 players. Also the player-updates are decoupled from the server tick-rate. A higher tick rate does not improve hit reg, while a lower tick rate can cause problems. But again, this doesn't happen on servers with a reasonable player count.
Also keep in mind, that NS2 is not comparable to any kind of shooter. What does the server need to calculate in BF3? Player-Positions, -Directions and Status. Vehicles. Projectiles. CapturePoints. Thats it. NS2 has much more game logic than that. Unmanned vehicles don't create more load than dropped weapons. Manned vehicles don't create more load as the player already does. But in NS2 you got so many dynamic things, like buildings and logic connected to this buildings, that it needs more CPU-power to calculate it. On top of that comes the LUA that isn't the fastest.
If you look into this game in more detail, you will see, that it has simply more demand than the default shooter. It is heavier to calculate.
The hitbox on skulks (and everything else) is pretty tightly bound. There's a console command 'collision damage' that'll show the collision meshes for hurting things ingame. A 'hitbox' isn't really the right term nowadays, as you'll see!
Hey max!
I noticed on your twitter feed you mentioned Screen Space Reflections (judging that these are just cube maps). Do you plan on implementing some sort of hybrid solution between the two as seen in the most recent crytek games?
Ex...
Depending upon angle of inflection use SSR... otherwise blend to cube map.
Possibly -- I started out using only SSR because of the nice advantage of being fully dynamic, but when you filter out all of the artifacts it limits them a lot. Then I switched back to something I implemented when we were doing the exo reveal trailer (but we didn't release) which is a sort of "local" cube map. It doesn't show in this particular shot, but it makes the reflections work a lot better than a standard cube map where everything that is being reflected is assumed to be infinitely far away. I may layer in SSR on top of that as a "high" reflections setting, but the quality of reflections I'm getting out of the cube maps makes me pretty satisfied for the moment.
For those that are wondering why this feature is being added, it's there to support the new Descent map, which is coming in the content patch. It has a very different look than the existing maps, which really makes this feature shine. This shot of Veil was sort of an accident and doesn't reflect what it will actually look like in game.
I'll be keeping these on (if there is a disable option), my rig can take it... I have a job and work for a living so I'm not on an old piece of shit PC. More importantly I buy games my PC can handle and don't expect it to do things it physically cannot do.
[...]this feature is being added [...]to support the new Descent map. It has a very different look than the existing maps, which really makes this feature shine. This shot of Veil was sort of an accident and doesn't reflect what it will actually look like in game.
Sorry to be a major killjoy but, as nice as it looks, I would have thought this would be waaay down on the list of priorities.
Your understanding of how game development works is severely lacking, and people reading your posts would do well to not confuse your assertiveness with wisdom.
hugh, can you ask one of the guys about the dx9 thing. was that just because that was what was released back at the time of the creation of the engine, or another reason. also is it possible to update to say dx10 or it is what it is. just curious, how that works.
SPARKS Direct x based?!?!? well in that case I demand reflections, refractions, and full transparency support with the next update!
sorry to go off topic here but, in layman's terms; why is there issues with rendering transparency properly? with model shaders it appears to be done through an emissive map rather than an opacity map but I couldn't find a method for doing this with world geometry. I'm also curious to whether this will change in the near future? There's not a lot of documentation on the shader system and I only have the existing content and my personal experiments to go on. Thanks
I asked Max about this a couple of years ago so my memory might be dodgy, but what I remember him saying is that with the deferred renderer that Spark uses, it was a significant technical hurdle to compute lighting and especially shadow through "proper" transparency to a quality that he considered worth doing.
Hey max!
I noticed on your twitter feed you mentioned Screen Space Reflections (judging that these are just cube maps). Do you plan on implementing some sort of hybrid solution between the two as seen in the most recent crytek games?
Ex...
Depending upon angle of inflection use SSR... otherwise blend to cube map.
Possibly -- I started out using only SSR because of the nice advantage of being fully dynamic, but when you filter out all of the artifacts it limits them a lot. Then I switched back to something I implemented when we were doing the exo reveal trailer (but we didn't release) which is a sort of "local" cube map. It doesn't show in this particular shot, but it makes the reflections work a lot better than a standard cube map where everything that is being reflected is assumed to be infinitely far away. I may layer in SSR on top of that as a "high" reflections setting, but the quality of reflections I'm getting out of the cube maps makes me pretty satisfied for the moment.
For those that are wondering why this feature is being added, it's there to support the new Descent map, which is coming in the content patch. It has a very different look than the existing maps, which really makes this feature shine. This shot of Veil was sort of an accident and doesn't reflect what it will actually look like in game.
Well I for one hope you add in a high setting with SSR layered on top!
Big fan of dynamic objects being picked up in "some" reflections!
Thx for answering my question max, Interested to hear about this cube map implmentation.
Also... no reson to justify adding this graphical effect all. We all know you work hard on improving Spark in terms of features and performance...
Sure mate - Spark uses 'Direct3D9' for part of its graphics system. DirectX is a broader standard, encompassing DirectSound, DirectInput, and other bits and bobs. These days, engines are often referred to as being 'DirectX9/10/11' even if it's just part of their rendering process. So while not strictly, technically correct, it would be colloquially acceptable to refer to Spark as 'DirectX9' engine. Similarly, while Direct3D11 will only make up part of CryEngine 3, people in the gaming work refer to CryEngine 3 as a DirectX11 engine.
Now, why doesn't Spark use Direct3D11? Wasn't Direct3D9 released way back before humans started using stone tools?
That's a very complex question, and one that honestly requires a blog post on unknownworlds.com to do it justice. But I'll use another engine analogy here, to give a rough idea.
Internal combustion engines are systems that have been around for a very long time. Most engines used in cars, bar some fun oddities (I'm looking at you, rotaries!) are four stoke piston engines that operate using the suck-squeeze-bang-blow sequence.
Ever since the four-stroke was invented, new ancillary systems have been popping up to improve it. Sometimes, these improvements are clear-cut wins, and not incorporating them into a vehicle would be foolish. For example, lead-free fuels.
Other ancillary systems are not such clear-cut wins. For example, turbochargers and V-cylinder-layouts. Adding a turbocharger to an engine can have benefits: Recovering the energy from exhaust gases can increase power output and reduce fuel consumption. But they also add weight, slow throttle response and dull exhaust notes. A V layout has packaging and vibration-balance advantages, but can also increase weight and complicate integration of other systems.
So, while V's and turbochargers are considered 'modern' and 'cool' features, flat-layout naturally aspirated engines can still stomp them when properly implemented. No one would doubt the powerful yet efficient delivery of the VW TwinCharger engines, or the world crushing power of the Veyron's W16 Quad-turbo. But equally the 'older' technology used in the AMG M156 or BMW S62
engines do not stop them being equally, if not more brilliant.
So Direct3D11 - There are differences, and they can make rendering better. But they are not sure wins, and they are not necessarily the most efficient wins UWE could strive for. In practice, the Direct3D9 pieces of Spark could be converted to Direct3D11. With work, that could bring certain benefits to rendering. But Direct3D11 is not lead-free fuel. So greater benefits could be achieved by perfecting natural aspiration, and that is the path we are going down.
Remember too, there is an element of marketing in the Direct3D line. Microsoft, hardware vendors and yes game developers have inventive to attach a new, shiny brand to their latest products. To the less well informed customer, this brand can make 'superceded' product look inferior.
Looks great and nice too see that theres work going on on every frontline. Nevertheless, hold back update until I get my graphics card back which I sent in for repair on 16st January ( Cant play NS2 since that day. Altough i was surprised that i got at least 20-30 fps on gamestart and 80+ in ready room with my gtx240
Sorry to be a major killjoy but, as nice as it looks, I would have thought this would be waaay down on the list of priorities.
Your understanding of how game development works is severely lacking, and people reading your posts would do well to not confuse your assertiveness with wisdom.
I may layer in SSR on top of that as a "high" reflections setting
@Max - Here's an idea for an "Ultra" setting: Slap together a quick Sparse Voxel Octree Global Illumination system to handle specular reflections and indirect lighting in one fell swoop. No big deal, right? :P
Comments
Most people won't even be able to play with these kinds of settings/performance and you want people to record with them?
Maybe that's the reason why no "evidence" has been found yet.. Can we at least agree that server performance seems to impact hitreg and as such there are bound to be hitreg issues no matter what? At least as long as server performance stays as wonky as it is right now..
But nobody can tell me that there are "no hitreg" problems when Skulks, that should die to 12 LMG bullets, regularly need double the amount of that (unless they are running straight at the Marine).
my feeling is, if anything, it will be some hitbox/lag compensation problem that some players will 'feel' more than others. I'm not the best NS2 player by far, but I'm good enough to know that when I die and feel like my bullets didn't hit it is most likely that I didn't aim good enough.
I noticed on your twitter feed you mentioned Screen Space Reflections (judging that these are just cube maps). Do you plan on implementing some sort of hybrid solution between the two as seen in the most recent crytek games?
Ex...
Depending upon angle of inflection use SSR... otherwise blend to cube map.
The damage numbers which pop up are counter-intuitive as is the hit detection graphic (green blood spurt) - Your client can show you hitting an alien who is actually taking no damage in my personal experience, so you feel like you are hitting a Skulk but the server disagrees so it takes no damage. During this moment it causes your client to pop up the damage counter; which calculates you have done enough damage to kill the Skulk who has now proceeded to rip your face off.
The damage numbers that pop up are 'pure' not taking account of attack type and armour values, example - The marine rifle deals normal damage, a skulk with carapace has 70hp and 30 armour. Each point of armour takes 2dmg to remove vs normal attacks, so a base skulk has 90 effective health points and carapace skulk has 130. You shoot a carapace skulk, you do 110 damage, you know it has 70hp and 30 armour, it lives - this is counter -intuitive as you have done more damage than its HP+Armour values add up too.
This all adds up including the lag compression and probably frame rate issues to make the games hit registry feel VERY very sloppy. Sometimes you'll feel like your missing but be blowing Skulks into next week, other times you were sure you were on target and get beaten down again and again.
(src for hp values and armour information: http://steamcommunity.com/sharedfiles/filedetails/?id=121084402)
Will writing some application layer between the lua and engine fix this? Maybe, but I imagine it's just the net code needing a more efficient design, it seems to lock up like a traffic jam when it's busy.
(30 ticks with less than 30 people. It's been done for over a decade with the normal results we've come to expect, but not yet in this game. )
@Kalabalana: I have no problem finding servers that can hold the tick rate of 30 even in end game. Given you don't play on servers that are > 18 players. Also the player-updates are decoupled from the server tick-rate. A higher tick rate does not improve hit reg, while a lower tick rate can cause problems. But again, this doesn't happen on servers with a reasonable player count.
Also keep in mind, that NS2 is not comparable to any kind of shooter. What does the server need to calculate in BF3? Player-Positions, -Directions and Status. Vehicles. Projectiles. CapturePoints. Thats it. NS2 has much more game logic than that. Unmanned vehicles don't create more load than dropped weapons. Manned vehicles don't create more load as the player already does. But in NS2 you got so many dynamic things, like buildings and logic connected to this buildings, that it needs more CPU-power to calculate it. On top of that comes the LUA that isn't the fastest.
If you look into this game in more detail, you will see, that it has simply more demand than the default shooter. It is heavier to calculate.
P.S. This thread really derailed...topic is about render reflections.
For those that are wondering why this feature is being added, it's there to support the new Descent map, which is coming in the content patch. It has a very different look than the existing maps, which really makes this feature shine. This shot of Veil was sort of an accident and doesn't reflect what it will actually look like in game.
I'll be keeping these on (if there is a disable option), my rig can take it... I have a job and work for a living so I'm not on an old piece of shit PC. More importantly I buy games my PC can handle and don't expect it to do things it physically cannot do.
I see what you did there.
Your understanding of how game development works is severely lacking, and people reading your posts would do well to not confuse your assertiveness with wisdom.
I asked Max about this a couple of years ago so my memory might be dodgy, but what I remember him saying is that with the deferred renderer that Spark uses, it was a significant technical hurdle to compute lighting and especially shadow through "proper" transparency to a quality that he considered worth doing.
Well I for one hope you add in a high setting with SSR layered on top!
Big fan of dynamic objects being picked up in "some" reflections!
Thx for answering my question max, Interested to hear about this cube map implmentation.
Also... no reson to justify adding this graphical effect all. We all know you work hard on improving Spark in terms of features and performance...
Some people just forget where their manners are.
Sure mate - Spark uses 'Direct3D9' for part of its graphics system. DirectX is a broader standard, encompassing DirectSound, DirectInput, and other bits and bobs. These days, engines are often referred to as being 'DirectX9/10/11' even if it's just part of their rendering process. So while not strictly, technically correct, it would be colloquially acceptable to refer to Spark as 'DirectX9' engine. Similarly, while Direct3D11 will only make up part of CryEngine 3, people in the gaming work refer to CryEngine 3 as a DirectX11 engine.
Now, why doesn't Spark use Direct3D11? Wasn't Direct3D9 released way back before humans started using stone tools?
That's a very complex question, and one that honestly requires a blog post on unknownworlds.com to do it justice. But I'll use another engine analogy here, to give a rough idea.
Internal combustion engines are systems that have been around for a very long time. Most engines used in cars, bar some fun oddities (I'm looking at you, rotaries!) are four stoke piston engines that operate using the suck-squeeze-bang-blow sequence.
Ever since the four-stroke was invented, new ancillary systems have been popping up to improve it. Sometimes, these improvements are clear-cut wins, and not incorporating them into a vehicle would be foolish. For example, lead-free fuels.
Other ancillary systems are not such clear-cut wins. For example, turbochargers and V-cylinder-layouts. Adding a turbocharger to an engine can have benefits: Recovering the energy from exhaust gases can increase power output and reduce fuel consumption. But they also add weight, slow throttle response and dull exhaust notes. A V layout has packaging and vibration-balance advantages, but can also increase weight and complicate integration of other systems.
So, while V's and turbochargers are considered 'modern' and 'cool' features, flat-layout naturally aspirated engines can still stomp them when properly implemented. No one would doubt the powerful yet efficient delivery of the VW TwinCharger engines, or the world crushing power of the Veyron's W16 Quad-turbo. But equally the 'older' technology used in the AMG M156 or BMW S62
engines do not stop them being equally, if not more brilliant.
So Direct3D11 - There are differences, and they can make rendering better. But they are not sure wins, and they are not necessarily the most efficient wins UWE could strive for. In practice, the Direct3D9 pieces of Spark could be converted to Direct3D11. With work, that could bring certain benefits to rendering. But Direct3D11 is not lead-free fuel. So greater benefits could be achieved by perfecting natural aspiration, and that is the path we are going down.
Remember too, there is an element of marketing in the Direct3D line. Microsoft, hardware vendors and yes game developers have inventive to attach a new, shiny brand to their latest products. To the less well informed customer, this brand can make 'superceded' product look inferior.
A topic that we shall no doubt have to revisit!
Edited for spelling.
I want my JetStream 680 back
Not to mention glass materials...
Above and beyond Hugh, thank you so much!
Awesome explanation! A++ would read again
@Max - Here's an idea for an "Ultra" setting: Slap together a quick Sparse Voxel Octree Global Illumination system to handle specular reflections and indirect lighting in one fell swoop. No big deal, right? :P
EDIT: Adding some eye candy to this post: