[FS BladeKiller]

"Fun over realism" refers to Q3 physics and speed with realistic weapons and locales. It was not referring to not being able to make super realistic maps at all. We did support bots until our AI coder had to quit due to demands of his business.

[FS Frankie V]

Dark-knight, on 04 October 2015 - 04:42 PM, said:

I have a request for HD. can you please give Guns models, physics? So I'f I drop it, it falls. If I jump, move forward, and drop it, it throws it. If I shoot the gun on the ground it slides across the ground?

Any static object can have a physics applied that's just a check box setting and if it has a skeleton then rag doll physics could be used so something that would be easy enough to test as a while your at it.

[ds`killspree]

Hi Bladekiller,

Yes I mean also that not only because the limitations in quake3.

For me the unrealistic movement and even gunshots make the game I like to slide at full speed scoped and then make a kill that have everybody say luck.

I just hope You guy's do a little bit extra effort on making the complete package work well so that we can have lower tris maps if we want just so that the fps will stay high if we feel we need that. so for instance don't make nade explosions that is going to slow the whole game down.
Also the characters I know 56k tris characters is easily done in unreal but you have to consider the fact if you multiply this by 32 players than add the gun tris count and add the impact of explosions, smoke and stuff like that it's going to limit the possibilities for lower spec systems to keep up.
Right now i'm playing urban terror on servers with 20 players at 40 fps but i can play a game like advanced warfare at high settings with 80 fps.
In that game you can clearly see high poly models for cutscenes but low poly with baked on detail for actual in game.
This way you can have bigger maps more "playroom" before the map is going to impact the game fps instead of the game itself where we have no control over.
And i know also the coding for a.i is little bit tricky but very much possible in unreal to make it more realistic.
I would love to see bots taking cover or running and using more weapons as standard.
The community backs you up FS but you have to let us offcourse!
Easy to give something physics in unreal 4.

It will be cool to have movable guns nades in game you can prevent your enemy from picking up a gun when he is empty or shooting a nade out off the air.
Idk If it should come as standart in the game but more as a mod perhaps depending on the freedom we will get from FS,

Greetings,

This post has been edited by killspree: 07 October 2015 - 06:37 PM

[FS BladeKiller]

Stop comparing the Unreal 4 engine to Quake III Arena's engine. They are very different animals. Q3 used your CPU for a lot more stuff and that was not something we could change. Ledgeclimbing in Q3 takes a lot of CPU cycles which is one of the reasons we recommend only 16 players max on a server.

There are many ways you can optimize performance in UE4 like instancing so you can have 100 barrels in a map and only pay for one. You can make LOD's for every map object which includes all of your map if it is a mesh. In Q3 only the player models have LOD's. In UE4 even the terrain auto-reduces the level of detail as you run around it. Do a little research on LOD's and instancing in UE4 and start optimizing your maps. Think modularly. Make one window and then make instances of that window for everywhere else that will be used in the map.

We are not going to make this game in UE4 with the lowest resolution possible. That is not in our plans. I have no intention of doing this work and having it look like it does in Q3. I am sick to death of it always looking like crap in that engine. I am not doing stick figures and lego block maps. If that's what you want stick with Q3.

[ds`killspree]

BladeKiller, on 07 October 2015 - 07:41 PM, said:

Stop comparing the Unreal 4 engine to Quake III Arena's engine. They are very different animals. Q3 used your CPU for a lot more stuff and that was not something we could change. Ledgeclimbing in Q3 takes a lot of CPU cycles which is one of the reasons we recommend only 16 players max on a server.

There are many ways you can optimize performance in UE4 like instancing so you can have 100 barrels in a map and only pay for one. You can make LOD's for every map object which includes all of your map if it is a mesh. In Q3 only the player models have LOD's. In UE4 even the terrain auto-reduces the level of detail as you run around it. Do a little research on LOD's and instancing in UE4 and start optimizing your maps. Think modularly. Make one window and then make instances of that window for everywhere else that will be used in the map.

We are not going to make this game in UE4 with the lowest resolution possible. That is not in our plans. I have no intention of doing this work and having it look like it does in Q3. I am sick to death of it always looking like crap in that engine. I am not doing stick figures and lego block maps. If that's what you want stick with Q3.

Can I make a instance of a static mesh or do you mean a copy?

No you completely not getting my drift I'm not referring to the look or blockiness just making a example out of the area's where quake 3 can not be improved and unreal can like what you say and explain, I don't think hd urt should look exactly the same in the texture area or how you build your maps characters or animations that is a more artistic aspect but It should definitely be the same in what is possible and what not.

The area's where thing's can be improved where in quake3 it was not possible like what you explain about ledge climbing and stuff or for example the impact on the cpu for bots That is where the focus needs to be the system requirements are already higher for hd than quake 3 because you need a 64bit system but the fps in a map like tp if you did a conversion that does not impact the fps much like the original map in quake3 than you should get better fps if you where playing with a minimal recruited system for unreal 4 so a quadcore about 2,5 gb and a gtx240 because that is actually about the minimum needed today to play decent on a full 32 slot server on urt 4.x.
Currently on that version if you where to make a simple box room in radiant with absolutely nothing in it besides the walls and spawn some bots in it lets say 8 on my system I still reach about 40 fps playable but not great.
Putting how unreal 4 is going to look aside if you where to do the same in unreal hopefully we are not going too be let down.

I'm not making comparisons without reason it's just positive criticism hoping to inspire and letting you know how the community thinks.

Greetings,

This post has been edited by killspree: 07 October 2015 - 08:49 PM

[FS Frankie V]

killspree, on 07 October 2015 - 08:25 PM, said:

Can I make a instance of a static mesh or do you mean a copy?

I'm not making comparisons without reason it's just positive criticism hoping to inspire and letting you know how the community thinks.

Greetings,

Being able to harvest feedback directly from the community is a high priority and as mentioned network performance is still a bit of an unknown but since most of the game play in UE4 is handled by the client so network latency should be less than it is now in 4.2. Just like the alpha of 4.2 as well as testing we done with fstech1 we want to get a few servers set up as soon as possible to see what the hard numbers says and not just assume what the soft numbers is telling us.

Notes:

If you make a copy of an object it is by definition an instance of the copy. Instancing is not limited to just static mesh but to almost anything that is a copy of a run time asset. Materials for example can be instanced that contains parameters to change the texture behavior that you can modify the rendered material so that it looks totally unique but is still rendered as a single draw call. In theory you could make a singe texture atlas and use only one base material and make everything else an instance off of that one material.

All mesh objects is hardware rendered so even a low spec computer should preform better through GPU rendering over a 15 year old engine still bound to the CPU first established in 1999. In idtech3 very little is hardware rendered or gets any kind of boost from the GPU with the exception that mesh based objects preforms better than brush based construction.

This illustrates the differences nicely.



idtech3 uses Leonardo v1 where UE4 uses Leonardo v2 so a 50k character model should not have as much of an impact in UE4 as say a 2k player model in idtech 3.

Pushing polygons is no longer an issue as compared to draw calls and performance can be effected if the over use of material instructions is abused in the same manner that shaders use in idtech3 could be abused creating the same kinds of performance issues that could occur in 4.2/idtech3 based maps.


Unreal 4 has tools to be able to profile your map once it is done to drill down to what is causing a performance issue so the "new" process for developing a map is to build modular and through iteration the "new" best practice would to be to build it first and leave performance as a last pass before distribution to find the things that are actually causing drops in performance as a fact rather than a guess or to included degrading the art asset based on a false assumption that less would be better as far as performance goes.

So

Our motto is to make more than what is need as it's easier to make to much do less than it is not try to make not enough do more and our current character budget is 200k not because we expect them to be that high but because high detail offers the ability to decrease the asset resolution if and when it is required as a last pass before going into distribution mode. Besides have a 200k poly character in the set up menu cause run time game performance how? :D

With UE4 you can scale in favorer of performance using procedural features. You can for example increase the tessellation of an object to make use of high maps or go the other way by using auto optimization that would decrease the resolution of an object at X distance.

Decreasing quality for performance is just a check box than can be tied to a menu switch. You can turn things on and off as an engine feature that does not require any additional coding so if done right the same game can be compiled to almost any platform from high end desktop to tablets to cell phones.

Unreal 4 is made to be used by the client and not as another means for company X selling the tools they use with the same problems that they are having as part of making the games that they use "their" engine for. Over the past year performance has increased in UE4 on all platforms and if we spot an unreasonable performance hit we can supply Epic with the demo of the issue and "they" will fix it. Simple to say that if there is a inherited performance issue it's not our problem, like it is using idtech3, but Epic's problem as to client usability.

And yes

Bots are an issue as to performance when there are to many all at once "but" this is symptomatic of yet another modular component of the UE4 package that simply can be plugged in as a template and should not be considered as a fit to finish asset. Bots are also not a reliable means of establishing the performance curve as although the mesh is hardware rendered the AI behavior tree is still CPU bound and all of them are making decisions at the same time by way of blue print directions.

However.

Since it is a modular asset just like a 3rd person or vehicle template if the use of bots became a priority then at some point a map developer could have a choice between as many different bots made available by 3rd party sources like Epic's market place.

In all though.

Soft numbers do not mean much until we can set up a networked alpha test to compare against the soft numbers that we know but are currently assuming is correct so the expectation for "test" maps would be a combination of high resolution and detailed assets along with lower detail elements to be able to benchmark just were the line is drawn between what would be unreasonable and needs to be hacked or what was once "assumed" to be to much but could be discarded as a requirement in favorer of a well balanced experience of both performance as well as looking good when you get your ass fragged. :D

The long way around I guess to say build it first and make it preform (optimize) second based on what profiling tells you as to what you can not afford.

[ds`killspree]

Frankie V, on 07 October 2015 - 10:24 PM, said:

The long way around I guess to say build it first and make it preform (optimize) second based on what profiling tells you as to what you can not afford.

Let's wait until a playable version comes out i'm sure it will be great how long you going to keep us waiting I just can't wait anymore sry if you think i'm being negative like frankie say's we only want to encourage you guy's and inspire you giving our 2 cent's should not be held against us because we mean it well.

Greetings,

[FS Zenity]

You really can't compare Quake 3 and UE4 performance in a straightforward manner.

Think about it like this: Doom didn't just look worse than Quake because the designers chose to use less detail. It looked worse because the engine enforced some very severe (and clever) limitations to ensure that the game would run well on the hardware of the time. Quake lifted those limitations and focused on newer hardware, which raised the minimum requirements. Now it wouldn't make sense any more to make a level as simple as a Doom level, because any hardware capable of running Quake well in general, could easily deal with a much higher detail level without breaking a sweat.

It's the same with UE4 and Quake 3. Minimum requirements are higher, and this is true even for simple box levels, which Quake 3 is optimised for. There is no point in comparing detail level to Quake 3 maps, when any hardware fast enough to run UE4 well could easily handle a lot more without it making any noticeable difference.

It doesn't take that much to run UE4 well, and anyone with a semi-recent desktop PC should have no problem. If it's not a gaming PC at all, then a simple GTX 750ti upgrade will fit almost any box and instantly turn it into a next-gen gaming PC for roughly 100 pounds.

Old laptops in particular can be more problematic of course, but here you have to be reasonable with expectations. Most of them are not made for 3D gaming and especially not fluid competitive gaming, so if anything it will serve you well in this regard for a few years. Quake 3 came out 15 years ago, in computing terms that is ancient history.

[ds`killspree]

Zenity, on 09 October 2015 - 04:17 PM, said:

You really can't compare Quake 3 and UE4 performance in a straightforward manner.

Think about it like this: Doom didn't just look worse than Quake because the designers chose to use less detail. It looked worse because the engine enforced some very severe (and clever) limitations to ensure that the game would run well on the hardware of the time. Quake lifted those limitations and focused on newer hardware, which raised the minimum requirements. Now it wouldn't make sense any more to make a level as simple as a Doom level, because any hardware capable of running Quake well in general, could easily deal with a much higher detail level without breaking a sweat.

It's the same with UE4 and Quake 3. Minimum requirements are higher, and this is true even for simple box levels, which Quake 3 is optimised for. There is no point in comparing detail level to Quake 3 maps, when any hardware fast enough to run UE4 well could easily handle a lot more without it making any noticeable difference.

It doesn't take that much to run UE4 well, and anyone with a semi-recent desktop PC should have no problem. If it's not a gaming PC at all, then a simple GTX 750ti upgrade will fit almost any box and instantly turn it into a next-gen gaming PC for roughly 100 pounds.

Old laptops in particular can be more problematic of course, but here you have to be reasonable with expectations. Most of them are not made for 3D gaming and especially not fluid competitive gaming, so if anything it will serve you well in this regard for a few years. Quake 3 came out 15 years ago, in computing terms that is ancient history.

Hi Zenity,

Thanks for the reply very use full I have been learning more about level streaming lod's instances and the overall performance benchmark for unreal 4.

I have not found any benchmark at all comparing the performance you will get in unreal 4.
It is limited to your hardware.
Therefore I have these questions basically split up into two sections.
The part that will be hard coded by fs so the game itself without considering the performance impact of the map.

Characters

Weapons

In game effects / hardware settings

Will these things get changeable lod's that we can manually set higher and lower if you want to be able to play the game on the minimal lod setting for each mesh so the things listed above?

3rd party maps / engine mods

Will these things include the ability to have custom weapons / characters or vehicles in it?

Greetigns,

This post has been edited by killspree: 09 October 2015 - 05:45 PM

[FS Frankie V]

killspree, on 09 October 2015 - 05:42 PM, said:

Will these things get changeable lod's that we can manually set higher and lower if you want to be able to play the game on the minimal lod setting for each mesh so the things listed above?

All of the questions you ask could or maybe answered based on this one question based on just the edit environment differences between UE4 and GDK as well as how the idtech3 engine "has" to have art asset parsed so they conform to hardcoded requirements.

In idtech3 to ensure the best possible performance by default the map designer has to build or put into place elements that trades detail in favor of what would be assumed to unquestionable increase performance that results in dated graphics of an engine built in 1999.

As a theory or as a concept UE4 is a nextgen engine that is being built as a top down design tool that does not assume that art has to be degrade in favor of performance and favors adding features that allows the designer to make design decisions based on regressive testing and observation as to overall impact.

With in our closed development environment it's easy to prove or modify the code as well as art design as to impact to both quality and performance as we can conform both to the needs of the design and not what is necessary as to what has to be done as a deliverable game.

As an example Mykonos as a test during development the statues is an excessive and abusive 200k in polygons built into an environment that could run with in idtech3 based on the hardcoded limitations with the intention that during live testing could be used during regressive testing to prove or disprove what to be honest can only be an assumption with out provable demonstration. In other words "trust" what I'm saying is true. ;)

But.



This is where providing hard answers becomes difficult as performance techniques has a proven history based on a deliverable result with the addition of such techniques being made available to the accepted knowledge base which is what my effort with "Working With Power Tools" is all about. I'll get to LOD's in a bit.


Also still on the list to be proven or disproven is the need to degrade to the point that loss of detail is required to the point of diminished returns due to the problem of pushing polygons has been solved with the introduction of the GPU and in my experience as far back as the 8800 GTX hair dryer.

Demonstrable proof.

https://www.youtube....4&v=IQ_BWblteQU

All of this of course does not mean that performance has to be ignored in favor of detail but with UE4 the process of priority does change of what needs to be done when and the addition of an LOD is super ease as to the need for any given art work as part of the optimization and polish process that would be considered as being "process" that is need to produce a deliverable and not waste a lot of time of including a process that may or may not be required based on demonstrable proof.

So in the case of Mykonos yes 200k is excessive be it proven that statues do impact performance or not but so what as procrastination with UE4 is an acceptable technique. ;)

So bottom line we really don't know the back end until we get there and demonstrable proof is added to the knowledgebase but UE4 does have the tools necessary to prove or disprove performance impact long before it becomes a deliverable which of course you can't really do with idtech3 GDK and hard coded specs that are 15 years old.

Also

The quick answer to all of your questions "yes" if you trust me. ;) Everything else is just tested theory.