Unreal Engine 4, Unity 5.. Torque 6?

  • 1
  • 4
  • 5
  • 6
  • 7
  • 8
71 posts Page 6 of 8
HeadClot
Posts: 78
Joined: Sat Feb 07, 2015 1:29 am
by HeadClot » Mon Mar 30, 2015 6:32 am
@ andrewmac - I can get you a proper terrain height map for testing. I have a copy of World Machine :)

I am also posting several references for you Andrew. These will be helpful. :)

http://osgearth.org/ - Open Scene Graph Earth - I personally would advise using this as a reference as it is under the LGPL license. :)

http://bitbunch.eu/chain-command-dev-bl ... bal-scope/ - How the game Chain of Command is doing their terrain rendering and LODs. :)

- HeadClot

EDIT: Totally forgot about this but Nvidia has made their Physx Library open source for registered nvidia developers on Github worth checking out if you do not have a physics engine yet :)

https://github.com/NVIDIAGameWorks/PhysX

https://developer.nvidia.com/physx-source-github
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Mon Mar 30, 2015 4:04 pm
@
User avatar
HeadClot
: Yeah, if you wouldn't mind sending over some heightmaps + textures from World Machine that would be great for testing. I don't know what formats/options it has for spitting out textures in terms of blending, etc, but send over whatever it spits out from normal usage and I'll try to ensure that the terrain system supports it.

I have L3DT myself so I'll try to make sure it works from there as well.

I'll definitely take a look over the various articles and implementations as I expand it. I'm thinking I should be able to use reduced precision versions of the terrain cells at a distance to keep performance up on large terrains.
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Tue Mar 31, 2015 2:57 am
I couldn't stand looking at the rough edges and poor texture quality anymore so I added nvidia's FXAA and autogeneration of mipmaps (on the CPU, not GPU) for textures. It's noticeably slower to load with the levels with the generation time, especially sponza, so I'm going to have to introduce some kind of processed/compiled texture file that sits next to the texture after it's been loaded.

FXAA:
Image

Mip Maps:
Image
HeadClot
Posts: 78
Joined: Sat Feb 07, 2015 1:29 am
by HeadClot » Wed Apr 01, 2015 10:57 pm
Hey @ andrewmac - Just a thought have you considered charging for this engine? Or would that not be possible? I personally would like to see a patreon set up to fund development of Torque 6 . :)

Just curious :)

Also got a few more resources for you -

Behavior Trees and how they work - http://www.gamasutra.com/blogs/ChrisSim ... y_work.php

Behavior3JS - http://behavior3js.guineashots.com/ - Written in Javascript but could be useful for making your own behavior tree system. :)

https://vimeo.com/2007054

Animation Blending - http://sourceforge.net/projects/tecnofreakanima/ - I am not sure what license this is under as it is not specified so best used as a reference.
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Thu Apr 02, 2015 2:56 pm
Hey @ andrewmac - Just a thought have you considered charging for this engine? Or would that not be possible? I personally would like to see a patreon set up to fund development of Torque 6 . :)
The engine will be completely free and MIT licensed. As far as setting up a patreon/gratipay, it's something I'll consider in the future, probably after an actual release, but right now taking money from anyone would make me feel obligated to them, and I mainly just enjoy doing this a fun side project.

I started a thread (http://forums.torque3d.org/viewtopic.php?f=32&t=158) in the new Torque 6 section regarding animation blending, I'd apreciate and opinions and/or information you or anyone else can add to the post. Animation blending is not my strong area. I can code it, but I've never designed a blending system before.
lowlevelsoul
Posts: 23
Joined: Mon Mar 30, 2015 10:02 pm
by lowlevelsoul » Wed Apr 08, 2015 3:09 pm
I have a small question about the rendering pipe-line.

It sounds like you're using deferred rendering/shading (one lighting model + one material model) with the fact that custom material types use a forward renderer. Is this the case?

Why not use deferred lighting? I don't know how familiar you are with the technique, but it's a lot like deferred shading/rendering. The pros/features are:-
  • You still have one lighting model
  • Custom material types can be supported in the standard lighting model, assuming they stick to certain conventions
  • The G-buffer is much smaller - no need to store per-material parameters since material colours are fetched after pre-light/light pass
  • You only need to have a single render target active in each pass, making it more portable for mobile
  • Hardware MSAA can be enabled rather than using a custom post-process
The negatives (if you can call them that) are :-
  • Geometry has to be drawn twice. First during the pre-light and secondly during the material pass. And I guess also again during the shadow pass.
  • You'll still have to perform the transparency/effects rendering with forward lighting
Apologies if you had already considered this and rejected the technique because of reasons I'm not aware of :)
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Wed Apr 08, 2015 5:18 pm
With rapidly increasing polycounts in scenes I find the geometry prepass to be cumbersome. I believe most people have come to a similar conclusion as there is not many engines recently using deferred lighting. UE4, Unity, CryTek, they all switched back to deferred shading with their most recent engine iterations.

While I generally try not to make decisions based solely on what others are doing, seeing them all switch to deferred shading helped to validate my opinion that doing a geometry prepass with millions of polys isn't worth it anymore. It seems to me like deferred lighting came out of a time when GPUs were better at rasterization than shaders. You're basically trading more triangles for less memory usage and fill, which made sense when the scenes didn't have millions of polys.

What really interests me is techniques like Forward+, but in order to support them I need compute shader support and it gets messy trying to have multiplatform support with required compute shaders. This is becoming less and less of a problem, so while I'm continuing with deferred shading for now, the rendering system is pretty simple and I believe I could change it for different techniques pretty easily, so in the future I may pursue a more modern technique such as Forward+, Clustered Deferred, etc.
lowlevelsoul
Posts: 23
Joined: Mon Mar 30, 2015 10:02 pm
by lowlevelsoul » Wed Apr 08, 2015 9:48 pm
With rapidly increasing polycounts in scenes I find the geometry prepass to be cumbersome. I believe most people have come to a similar conclusion as there is not many engines recently using deferred lighting. UE4, Unity, CryTek, they all switched back to deferred shading with their most recent engine iterations.
So this is an argument that I've heard before, and while I do agree that on the surface it seems like a valid argument, I'm not totally convinced about this. Before I offend you, let me say that you're well within your right to think differently and I'm not saying that you SHOULD do the rendering a certain way. If you think deferred shading is the best way forward, then go for it.
LukasPJ
Site Admin
Posts: 388
Joined: Tue Feb 03, 2015 7:25 pm
 
by LukasPJ » Wed Apr 08, 2015 10:49 pm
@ lowlevelsoul I believe T3D switched to Deferred Shading because it's necessary for PBR. That must be a good motivation to use that over Deferred Lighting :P Not sure why the switch was necessary, but it was the primary motivation for switching.
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Wed Apr 08, 2015 11:22 pm
@ lowlevelsoul : I'm not easily offended and very much welcome the technical discussion. I don't think I can present a better argument than the one given in this article:
http://gameangst.com/?p=141 please read the comments as well, the author addresses a number of concerns and Wolfgang Engel, the man who invented Deferred Lighting, even shows up.

I did a lot of research on the topic a year ago and switched T3D from Deferred Lighting to Deferred Shading. We saw a slight performance increase (though that wasn't the goal) and a simplified pipeline.

My rendering pipeline in Torque 6 is pretty clean, simple and flexible. If a reason comes up where deferred lighting would be a massive benefit to a particular platform I will gladly implement it as an option. Unity 5 currently supports forward, deferred shading, and deferred lighting. I'm not opposed to making this an option if someone can present a strong argument for it. It should be noted that it's been stated a big reason Unity 5 has deferred lighting still is because no one had time to remove it. They added Deferred Shading on top of it for Unity 5 and left Deferred Lighting in place due to time constraints. That's just about every major engine recently making the switch from Deferred Lighting to Shading :P Again, I'm not into jumping on bandwagons but when I see people like Martin Mittring, who was a huge proponent of deferred lighting a few years ago, switching Unreal Engine to Deferred Shading, it really made the decision a lot easier haha.
  • 1
  • 4
  • 5
  • 6
  • 7
  • 8
71 posts Page 6 of 8

Who is online

Users browsing this forum: No registered users and 2 guests