Unreal Engine 5 = Game Changer

In my case I have resolve the problem way before I resolved the code. Look at how long it takes me to have my GI working, it's not entirely due to code, but code is a factor too, one where my brain say "F this I'm out", you have no idea how painful it is, now you could say my code is probably not well written ... well I let you judge for yourself the current state.

Spoiler: this is already too much to look at for me

Code (CSharp):

1. Shader "MAGIC/BoxTEST"
2. {
3.     Properties
4.     {
5.         _MainTex ("Cubemap Atlas", 2D) = "white" {}
6.         _DirectLightMap ("Direct Lighting", 2D) = "white" {}
7.         //_MainLight ("Main Light", Vector) = (1,1,1,1)
8.         //_Origin ("Origin", Vector) = (0,0,0,0)
9.     }
10.     SubShader
11.     {
12.         Tags { "RenderType"="Opaque" }
13.         LOD 100
14.         //Cull Off
15.         Pass
16.         {
17.             CGPROGRAM
18.             #pragma vertex vert
19.             #pragma fragment frag
20.             #include "UnityCG.cginc"
21.             #include "MAGIC.cginc"
22.  
23.             struct d
24.             {
25.                 float4 vertex    : POSITION;
26.                 float2 uv        : TEXCOORD1;
27.                 fixed4 color    : COLOR;
28.                 fixed3 normal   : NORMAL;
29.             };
30.  
31.             struct v2f
32.             {
33.                 float4 vertex    : POSITION;
34.                 float4 wpos     : TEXCOORD1;
35.                 fixed4 color    : COLOR;
36.                 fixed3 wnormals : NORMAL;
37.             };
38.  
39.             v2f vert (d v)
40.             {
41.                 v2f o;
42.                 o.wpos = mul(unity_ObjectToWorld, v.vertex);    //world position
43.                 o.vertex = UnityObjectToClipPos(v.vertex);      //screen position
44.                 o.wnormals =UnityObjectToWorldNormal(v.normal); //normal to world normal
45.  
46.                 o.color = float4(v.uv, 0,1);// v.color;
47.                 return o;
48.             }
49.            
50.             sampler2D _MainTex;
51.             float4    _MainLight;
52.             float4    _Origin;
53.  
54.             //lightcolor,
55.             //mesh position to align with grid potentially in vertex clamping using the bounding box
56.             //pass the size and grid range, compute cell size
57.             //pass number of samples over hemisphere
58.             fixed4 frag (v2f i) : COLOR
59.             {
60.                 //set size
61.                 const float size    = 4;
62.                 const float2 cuberange = float2(16,16);
63.  
64.                 float  epsilon      = 0.000001;
65.                 float3 origin       = _Origin.xyz;
66.                 float3 worldnorm    = normalize(i.wnormals) + epsilon;
67.                 float3 pos          = i.wpos.xyz - origin + 0.001;
68.  
69.                 //hash position to read the right cubemap in the atlas
70.                 float3 hashpos      = floor(pos / size);
71.                 float3 hash_offset  = hashpos * size;
72.                 float2 hash_id      = max(float2(0,0), min(hashpos.xz, cuberange));
73.  
74.                 //box projection
75.                 float3 cubecenter   = hash_offset + (size / 2);
76.                 float3 mincube      = hash_offset + 0;
77.                 float3 maxcube      = hash_offset + size;
78.                 float3 projected    = BoxProjectVector(pos, worldnorm, cubecenter, mincube, maxcube);
79.                
80.                 //sampling the atlas
81.                 float2 octnormal    = (PackNormalToOct(projected) + 1) / 2;
82.                 float2 samplepos    = (octnormal + hash_id) / cuberange;
83.  
84.                 //light test
85.                 float3 light        = normalize(_MainLight);
86.                 float  ndotl        = saturate(dot(light.xyz, worldnorm));
87.                 float  skyocclusion = saturate(dot(float3(0,1,0), worldnorm));
88.                 //skyocclusion *= skyocclusion;
89.  
90.                 //shadow sampling, box projected and direct
91.                 float3 lightproj    = BoxProjectVector(pos, light, cubecenter, mincube, maxcube);
92.                 float2 lightbox     = (PackNormalToOct(lightproj) + 1) / 2;
93.                 float2 shadowbox    = (lightbox + hash_id) / cuberange;
94.                
95.                 float2 lightdirect  = (PackNormalToOct(light) + 1) / 2;
96.                 float2 shadowdirect = (lightdirect + hash_id) / cuberange;
97.                
98.                 //gather loop
99.                 const float PI = 3.14159265359;
100.                 const float phi = 1.618033988;
101.                 const float gAngle = phi * PI * 2.0;
102.                 const int numSamples = 64;
103.  
104.                 float4 gi;
105.                 float4 traceResult;
106.  
107.                 for (int i = 0; i < numSamples; i++)
108.                 {
109.                     float fi = (float)i;
110.                     float fiN = fi / numSamples;
111.                     float longitude = gAngle * fi;
112.                     float latitude = asin(fiN * 2.0 - 1.0);
113.                    
114.                     float3 kernel;
115.                     kernel.x = cos(latitude) * cos(longitude);
116.                     kernel.z = cos(latitude) * sin(longitude);
117.                     kernel.y = sin(latitude);
118.                     kernel = normalize(kernel + worldnorm);
119.                     if (i == 0){
120.                         kernel = float3(0.0, 1.0, 0.0);
121.                     }
122.                     traceResult += 1;// ConeTrace(voxelOrigin.xyz, kernel.xyz, worldNormal.xyz);
123.                 }
124.                 traceResult /= numSamples;
125.                 //gi.rgb = traceResult.rgb;
126.                 //gi.rgb *= 4.3;
127.                 //gi.rgb += traceResult.a * 1.0 * SEGISkyColor;
128.                 //float4 result = float4(gi.rgb, 2.0);
129.  
130.                 //cubemap result
131.                 float4 cubesample   = tex2D   ( _MainTex, samplepos );
132.                 float4 boxshadow    = tex2Dlod( _MainTex, float4(shadowbox,0,7));//tex2D(_MainTex, shadowtest);
133.                 float4 directlight  = tex2Dlod( _MainTex, float4(shadowdirect,0,4));
134.                 float4 occlufactor  = tex2Dlod( _MainTex, float4(shadowdirect,0,7));
135.                 float4 occlusion    = occlufactor.b * (skyocclusion + 1.0);
136.                 return occlusion;
137.             }
138.  
139.             float4 traceRays(){
140.                 //box sample cubemap to get uv
141.                 //use uv to sample direct lightmap to get illumination
142.                 //mask sample by skybox mask
143.                 //sample skybox
144.                 //mask skybox by skybox mask
145.                 //return sample + skybox
146.             }
147.             ENDCG
148.         }
149.     }
150. }
151.  

 

Shaders are just difficult period but then I treat them as a completely separate field because you need to be somewhere between an artist and a programmer to be able to do anything impressive with them.

 

THIS part is verbatim what they said about nanite

I think this is occam razor approved

So unity is probably half way through a proof of concept.

edit:
another paper for archive
http://hyperfun.org/FHF_Log/Bastos_GPU_ADF_SMI08.pdf

 

Capcom chose Unreal to develop Street Fighter V and Square Enix use it to create Final Fantasy 7 Remake, because Unreal is open source and Epic have vast experience in AAA game development.

 

Only in the sense that the source is available to every developer and you can muck around in it.

 

yeah but it's not the shader that is hard, I'm specifically talking about text coding, I already knew what I wanted to do 6 month ago, but parsing the text and having to translate back and forth the concept is what wreck the brain. Else I would have start implementing nanite speculation right away, and I have been dealing with text code for 20 years, so I'm not a novice, it's just for some people it remain painful no matter what, tracking those stupid text and having to deal with so many distraction that get in the way of parsing, which is why a lot of my concern look petty to a "compatible" programmer, brackets and ; annoy me to no end, all during 20 years. If anything shader and swizzling syntax is a god send to reduce the burden in shader. The struggle is real, I already shared c# snippet in other discussion of the same acabit, and I got yell for praising python (the horror when I learned about Bython https://github.com/mathialo/bython sharing your own perverse pleasure to see unnecessary bracket everywhere. Text is pain.

 

The post you're replying to wasn't saying "Unreal is bad," it was saying "Unreal is expensive."

Multi-million-dollar AAA companies using it doesn't exactly counter that argument.

 

For the computation of dynamic GI, the view is partitioned in three areas. At close range voxels are used, mid range volume textures with SDF and height maps for long ranges. Can't remember the source but you can find it directly on Brian Karis twitter account.
[Edit] I'm trying to find the source and update this post accordingly.

 

Back to the topic:

https://www.bbc.com/news/business-5...dxt/gaming&link_location=live-reporting-story

Interesting is the summary at the end:

(bold by me)

 

I shared the quote already earlier, what it mean is not distance but scales, ie large details is voxel, medium is sdf and small are resolve in screen space. They were specifically talking about lumen.

My guess being that they unified mesh and lighting, mean they use the same structure for both, as it make virtualization (paging) easier to be done once.

BTW here is a very crude similar idea done in unity
http://colourmath.com/2018/development/signed-distance-fields-in-unity/

 

It does, though. Big companies are 100% about making games as cheaply as possible while at the same time charging for them as much money as possible. The main point of unreal engine isn't programming language, but the fact that once you download It, you have tons of pre made "components" for most of the cases and all of them are mature and don't need constant rewriting like unity packages. You only download a new version of the engine, and you can immediately start making a new game. No broken packages that are in the preview for 2 or more years, no problems with broken render pipelines, no dreams about dots that will be usable in a few years, and most important - no upfront payment, so even If you have chosen engine poorly, the company always can get their team to something else with lower cost than in Unity.

 

Right,
That is exactly what I'm doing with my primitive shadows system only that there's no pre-volume bake and I still need the move everything into a compute shader for more efficiency.

 

I'm not convinced of this. This doesn't jive with Rockstar reframing every single cinematic to add black bars. This doesn't jive with many AAA companies still making their own engines for games. This doesn't jive with Witcher 3 and AC Odyssey (and no doubt others, but those are the two I've familiar with) releasing hours of free content up to a year after the game released, in addition to extremely beefy DLC. And for that matter, it doesn't jive with how massive, and massively expensive to make, AAA games have gotten when they still only cost $60. Exceedingly profit focused, yes. Games made "as cheaply as possible" and costing "as much money as possible"? Eh.

 

Rockstar invested into multiple engines during their lifetime, and basically they don't gain much from switching to Unreal from their RAGE at this point.
Free DLCs one year after release is largely used to build positive company image and ensure people buy next products.
AAA games being massive while still costing $60 happens because of insane investment into advertising, to the point where half of the budget can be spent on publicity.

And in case of games like Final Fantasy, Mortal Kombat, they don't have a very established toolchain and needed something stable fast. Hence they choose Unreal.

So, the way i see it, everything they do has a reason, and final goal is likely maximizing profits.

 

Comparing biggest and most successful AAA companies in the world to everything rest and saying that somehow exactly the same is really pointless. They have nothing in common besides being in the same industry and making games. Rockstar is in a different league that unreal isn't even targeting to.

But even then, what's wrong with my statement? Hasn't Ubisoft switched to blender because It's cheaper? Hasn't most of the companies you are talking about moved big part of their stuff to developing countries, so they can spend less money? All of this while rising their prices all the time either by actually rising the price or introducing dlcs/mtx and other stuff? They are trying to lower their cost as much as possible while at the same time make as much money as possible, but they are in a different situation than most of the industry and does need their own engine. The lower you go from there the more appreciation you will find for ue4. Because It is cheaper to make generic games with ue4 rather than create your own engine.

 

I wasn't thinking about Rockstar with the engine comment actually, I was thinking about Ubisoft, who basically has a different proprietary engine for every big IP, or Sony, who has multiple engines across studios (Decima, whatever Dreams is) (though their status as a hardware developer makes them different), or Capcom's new engine they've used for DMC 5 and RE 7.

It's easy to say that free DLC builds goodwill, but on the surface it's a cost, and it's difficult to say how much return it has.

There's little doubt in my mind that AC Odyssey could have had half the content, be advertised the same way, and sell the same. That game is absurdly large.

In the end: maximizing profits--yes. "As cheaply as possible"? No.

 

Also people may have miss the big HD AAA crash that happen, symbolized by the crash of THQ, where the industry contracted from 270+ AAA studio to less than 50.

Also Ubisoft ANIMATION switch to blender, not ubisoft gaming divisions, and that's more so an ideological push rather than a monetary one.

 

Going cheaper when you can get the same quality (outsourcing asset production) is one thing. As cheaply as possible is quite another.

They aren't raising their prices, at least in the US. AAA games still cost $60. DLC and microtransanctions can of course bring in more revenue, but the base price for AC Odyssey, a game that has like 100 hours of content (and I'd say at least 40-50 of it meaningful), is the same as it was for the first games in the series. In my subjective opinion they're adding more content than they need to to sell the game, thus--not "as cheaply as possible."

 

You can't quantize everything precisely.

Freebies are the long game spreading across multiple titles. In case of freebies being actually developed after the release ate, in case of witcher 3 it is possible that they were sitting on extra money and decided to spend it this way.

By the way, Epic games with their grants is doing something similar. Those grants do not bring back profit, as they're funding competitors too.

Speaking of Ubisoft, the company seems to be tirelessly working to destroy their image even further and chase away all their fans. Basically, they were region/language locked for years with no legal way to obtain english title in my region. Recently epic store started selling english version of ubisoft games, BUT recently they went ahead and added a clause where they can nuke users account and all their games after 6 months of inactivity. Gotta admire their dedication to building infamy.

 

You mean, the base of the game cost $60 while at the same time every single developer is trying to push towards their "better edition" and putting mtx everywhere?

Also, amount of hours per dollar isn't really a scalable index, at least for a game developer. Depends on the content you might have to spend different amount of money per hour of gameplay. Ubisoft has tried to do everything to spend as little as possible on expensive parts of the game.

And in terms of how fast as a game developer you can do simple, generic elements of the game, whether we are talking about cut scenes, good-looking UI, realistic graphics, simple gameplay elements, AI and a good deal of other stuff UE4 was always better than Unity. What's worse, unity hasn't achieved anything significant in these terms due to their manager's incompetence.

 

Unreal is not open source. Plus, all of these engines, Unity-included, come with source when you are a AAA developer.

 

It might not be technically open source but anyone can get access to UE's source unlike Unity which still has engine level bugs from 6 years ago. Community could have fixed them ages ago if Unity shared source like UE does.

 

Even if it can export straight from zBrush and be able to render smoothly all those triangles, it isn't reasonable to do so. You could make a 30 second game that would take up the entire hardrive of a game counsel if you did that.

 

Why? If hardware and software can handle it, it is the natural next step.

Video games has been chasing high fidelity for a long time. So, if someone can provide higher level of detail, people will grab it.

Another thing is, in the long term, at some point zbrush level of details will be insufficeint.

 

This completely disregards the way cost scaling happens in AAA spaces.

 

You are assuming that the data remains in that format on a build.
If they are using geometry images, and Brian Karis's blog would imply that they are at least part of the picture, they wouldn't be.

 

Well, yes and no. I am never going to argue against having source access, considering how many times I have had to fix stuff in everything I use, but legally the community cannot fix an engine bug in UE4 in a shareable way. Of course, that doesn't necessarily mean much in this context but it is important not to throw around the term "open source" where it is not appropriate.

 

About that...

You can make patches.

For anything that does not fit into a patch there are pull requests.

 

Unreal does, however, review and potentially accept community fixes. There is an extra layer of bureaucracy, sure, but a lot of community fixes and new engine functionality still get "shared". It's not open source but in many ways it works the same for the end user, they still get that fix.

 

Just want to clarify: The primary thing I was arguing "against" was that AAA games are made "as cheaply as possible." The line of logic (going through the different replies and such) is this:

If AAA games are made as cheaply as possible, then introducing AAA games that use Unreal is an argument against "Unreal is expensive" (or more accurately, hiring programmers to work in Unreal is expensive).

If AAA games are not necessarily made as cheaply as possible, then introducing AAA games that use Unreal isn't necessarily an argument against "hiring programmers to use Unreal is expensive."

Interesting take on Ubi. They've actually done a lot to change their image: The Assassin's Creed series used to be every year like clockwork, now they tend to be every other year. R6 Siege and For Honour both released in a poor state, and they spent years fixing them. Ghost Recon Breakpoint released in a poor state and they've committed to fixing the problems, and delayed a bunch of their other games in response.

Not at all a fan of their actions with Epic's store, but I always bought their games on Uplay anyway.

They may be trying to push you towards other things, but they're still releasing gobs of content for that base price.

You're right about dollars per hour not being everything, but it's not just, like, Bloody Palace in DMC (just fighting enemies in a generic arena). The map is enormous and very detailed. That game has three separate storylines--of varying presentation level, true, but still a lot of effort put into unique content. It's not all just stealthing through bandit camps.

See above--the original statement was in reference to C++ vs. C# programmers. All of that may be true (I've never really used Unreal, so I don't know, but it may be), but does it balance out with the increased cost of a C++ programmer?

 

When using external source you should at least attribute it and quote it, otherwise it is plagiarism.

I'd also recommend to find a better hobby. Badmouthing unity and wishing its death, is not very productive in the long term.

 

You haven't been constructive at all. All you do is scream about Unity in comparison to UE4 whenever a thread comes up. You've done this for years and you've never been constructive. You're literally trying to accuse a productive forum member of being hired to do damage control.

 

I'm new here but I think superjay has a valid point, all I see are posts from mainly three people ,
Ryiah
neoshaman
neginfinity

Where are the rest of thousands of others. BTW, this thread is primarily regarding the render capabilities of the next upcoming UE and not much to do about DOTS, etc. I wish the mod moved most of these conversations to another thread.

 

Tell me the topic of this Thread?? It's not DOTS is it? Read Garry Blog, he said it best. I know the truth hurts about Unity.

 

A small studio. We started creating a game using Unity 5.6. We eventually migrated it to Unity 2019.3 with HDRP. We've had the occasional problem but nothing remotely like everyone is describing in this thread.

 

We're currently behind NDAs with everything related to the HDRP, but a few of our members created and released a game back in Nov 2018 when we were dealing with slow investors trying to decide if they wanted to fund us or not.

https://www.oculus.com/experiences/go/2269478696459386/

 

Why were you expecting a studio to just freely discuss everything we're currently working on?

 

...wow.

 

jayman got threadbanned and unable to reply, aparently.

------

Someone brought up SDF(signed distance fields) earlier, which made me wonder about some detail.

Distance fields have a problem when you raymarch them, and that is ray marching in parallel to the surface while being close to it. Because distance to nearest does not store direction towards that nearest surface, in this situation the algorithm exhausts number of steps as it is able to neither generate a hit nor move to a more spacious region.

Feels like I might be missing a piece of information here.

 

On related note, it is possible to see somebody's posting history even when they block viewing their profile. To do so, click on their name in the forum post, and you'll find "report"" and "ignore" menu along with clickable "messages" which will show their entire posting history.

Have fun.

 

https://www.eyeballistic.com/

To be honest based on the way you're responding I don't expect anything to please you no matter how detailed it is but here is a summary of my experience.

https://forum.unity.com/threads/i-knew-i-was-meant-to-be-a-programmer-when.884911/#post-5814844

 

Unity's UI model resembles that of Qt. If you worked with Qt before, it makes sense.

However, it is lacking in multiple departments. For example, automatic layouts don't work the same way as Qt ones do, and anchoring is reeeally awkward. It feels awkward.

On other hand, UI corresponds to unity event system and that...

That thing is bonkers.

Code (csharp):

1.  
2. ExecuteEvents.Execute<ICustomMessageTarget>(target, null, (x,y)=>x.Message1());
3.  

 

What is the current situation with this https://unity.com/products/multiplay

I remember the keynote presentation a long time ago, cannot find it anymore on youtube.

 

Performance is a major problem too. The Unite 2017 talk (check the spoiler) is half an hour long and it's a fast paced one because of how much information had to be covered on how to optimize Unity UI. If you don't know what you're doing you could very easily destroy your performance with it. I like to rewatch it regularly just because there's so much you can forget.

Spoiler: Unity 2017 - Squeezing Unity: Tips for Raising Performance

 

I removed several posts for being off-topic, pointless arguing and a few responses to some of those posts. This topic is clearly reaching its end of life. Any more pointless arguing or derailment will result in closure.

 

In the claybook talk, there is mention of some mitigation techniques i vaguely remember, something about lazy evaluations of swept sphere as cone tracing.

Edit: i checked, it start a 22:34 of the digital dragon claybook talk on YouTube. He does a coarse tracing prepass in a lower resolution then use the result to resolve the full resolution, got 6% performance increase over just a full rez direct pass, given that this edge case is not all pixels.

Edit: i still have no idea how you correlate texture with sdf as they would do in nanite potentially, i had the same problem with GIM but since gim is geometry i could get a patch based rasterization to get a final result, they have no concept of uv, how do they infer from sdf .... back to starting point.

 

Yesterday Rust founder (And founder of garry's mod) voiced alot of complaints. Rust is by far one of the biggest titles made in Unity so it carries alot of weight.

Though surprising that he believes you can achieve same performance with the classic OOP model

 

Your signature links to your “Project Exodus” github which assist people in “switching from unity to unreal”. What made you change your mind? I’m not asking facetiously, by the way. Just curious!

 

Unity needs something like this



From my understanding the library also integrates seamlessly in UE. Though for such a feature we need performance out of the box. Just sprinkle with assets without bothering with draw calls and materials. Bake tags and what not

 

https://garry.tv/unity-2020

He makes a ton of valid points, many that I echoed here before.
One take that I liked is why Unity is trying to sell DOTS as the magic cure for everything, when there are functions that would benefit everybody if they were on the backend.
I think that the bad feeling around these days is just that it still feels like a pipedream. ECS was introduced in 2016, and I bet no one would thought that in 2020 is still as much as a preview as it was yet, only with more promises queued on top. And not only that, there's the feeling that Unity works on something and let it die while they are searching the new thing, so there's this aura of uncertainty about all.
Today I'm quite happy with HDRP (but if it wasn't for amplify shader and their top notch support I couldn't have ported my game), Timeline is now usable, cinemachine was always pretty robust and keeps getting better.