Hard Light Productions Forums
Off-Topic Discussion => Gaming Discussion => Topic started by: Fury on November 05, 2009, 10:51:12 am
-
http://games.slashdot.org/story/09/11/05/1451256/Epic-Releases-Free-Version-of-Unreal-Engine?from=rss
http://www.udk.com/
I wonder if this UDK actually shows inner workings of the engine and whether some of the code could be reverse-engineered for fs2_open. Code such as OpenGL, OpenAL, shaders, physics, etc...
-
well this is unexpected, but cool.
-
Nice to see. Epic has taken some flak lately for various things, but they have continued to be excellent in supporting the mod communities, more than most companies. UT3 has a lot of good stuff available for it.
-
is there some free content available too?
even if it's not a lot, just one or two character models and a single map, just something to start you off with.
-
What's the catch?
-
Heh, oddly enough, I posted about this in the Programming Forum, didn't realise this was here :)
-
I wonder if this UDK actually shows inner workings of the engine and whether some of the code could be reverse-engineered for fs2_open. Code such as OpenGL, OpenAL, shaders, physics, etc...
You actually wouldn't really want to reverse engineer that code. There are many, many, many sources that show how to do those things in a more abstract fashion that could be applied to FS2 in a much more reasonable manner, preferably without making FS2 look like the over-processed-3D-crap that is Unreal.
-
over-processed 3d crap, what?
-
What Aardwolf said.
-
I gotta go with blackhole here. Most Unreal products look faintly, well, unreal. Plasticky. There have been a few that got past that barrier, though.
-
UE3 is an odd engine in that there is a lot of variation in the games that use it. Only UT3 has really used it to its full potential. All the other games I've seen on that engine look much worse.
At its best though, it looks great (probably second only to CryEngine 2) and is very scalable, running well on a range of hardware.
-
I gotta go with blackhole here. Most Unreal products look faintly, well, unreal. Plasticky. There have been a few that got past that barrier, though.
Isn't that more a function of art assets and/or lighting settings than the underlying engine, though?
-
The original Unreal (only in Glide mode) was one of the best looking games I had ever seen when it came out. It was the same era as half-life and it showed what a new engine was capable of as opposed to the old and busted Quake engine modifications that HL did. Granted we still know which one was the more popular game...
-
Yes, Unreal's graphics were miles ahead of everything else when it came out in 1998. I don't think anything really challenged it until Descent 3 and Quake 3 a year later, and even those were only better in some ways.
UT still holds up fairly well today, especially with the S3TC texture packages. In fact, I have yet to see any modern game match up to that level of texture quality.
-
Yes, Unreal's graphics were miles ahead of everything else when it came out in 1998.
And even then Unreal 1 was released with about 1/4 of the features the engine was going to introduce. :P
-
Yes, Unreal's graphics were miles ahead of everything else when it came out in 1998.
And even then Unreal 1 was released with about 1/4 of the features the engine was going to introduce. :P
And that's stil far more than the original Quake was going to have :P
-
I remember playing Unreal on a Voodoo card, and walking out of the prison ship for the first time...it was just amazing. The water effects still look good to this day, the lighting was superb, even the music was well done. Just never grabbed me as a whole, like Half-Life, which goes to show that a great game is more than the sum of its parts.
-
I gotta go with blackhole here. Most Unreal products look faintly, well, unreal. Plasticky. There have been a few that got past that barrier, though.
Isn't that more a function of art assets and/or lighting settings than the underlying engine, though?
Only if you actually change the stupid lighting shaders. Guess how many people bother doing that? Also, graphics engines impose a given look and feel on all the games that they render based on how they do things. Unreal is powerful, but its still based around a whole bunch of largely fixed-function ideas, like skyboxes. You simply cannot get a game built in Unreal to have skyboxes like Freelancer, because freelancer's graphics engine was built using modular skyspheres, and Unreal's actual graphics pipeline is not as modular as one would think (at least, in terms of efficient modularization. You can hack anything you want to any engine, but doing so often incurs enormous penalties). This is caused by the mindset of "Why would someone not want to use skyboxes?!" etc.
People don't seem to realize that a very tiny and very fast open-source graphics engine called irrlicht (http://irrlicht.sourceforge.net/) can run on any platform you throw at it, using directX, openGL, or its own software renderer. It even runs on a phone. It's not that impressive to look at, but its core functionality is rock solid, and it's FAST. You do not need to be a huge software company to write reliable software.
-
It's fast because the poly count and textures look like an ass.
-
So the aesthetic value of the assets affect the speed of the Engine?
Better not make good textures then, they'll make the thing run slower...
-
Are you seriously telling me that using say... a 512x512 texture is the same thing speed wise as using a 64x64 one?
-
From a hardware point of view, it's the speed of the pipeline that counts as much as the size of the texture, in fact, using a 64x64 texture can waste processor time on some of the newer cards, because the data is transmitted in blocks, and a smaller texture can introduce redundancies into the data.
-
Those newer cards are fast enough to make the point of engine speed pointless. And besides, if you are using the same textures (a 64x64 and a 512x512) to cover the same area, the 64x64 is going to be faster.
Anyway, if I was making a game with decent graphics, I'd much rather using an engine that was made to render stuff like this (http://images.google.pt/images?hl=en&q=unreal%203&um=1&ie=UTF-8&sa=N&tab=wi) instead of one that's usually used to render stuff like this (http://irrlicht.sourceforge.net/screenshots-projects.html).
-
Just because the demo of an Engine doesn't have commercial quality graphics, it does not neccessarily follow that the engine is incapable of handling that level, put those textures into the unreal engine, and you'd get pretty much the same results, only with too much specular.
As for the card itself, from what I understand, the data has to be processed outside the card and transmitted to it in a specific format, usually in 2 Meg chunks (iirc). The difference in time between rendering a 512 texture and a 64 texture is more or less immaterial, whereas the time required to transmit the two textures to the card itself is exactly the same. You might be able to transmit more textures in the 2 Meg chunk if using 64 x 64 but I'm pretty sure there are added complications to that as well.
The thing is, most Graphics cards are optimised for larger textures (256, 512 and 1024) and tend to work best using those sized textures, but it's just possible that the people using Irrlicht are programmers first and can't afford Epic's art department.
-
Just because the demo of an Engine doesn't have commercial quality graphics, it does not neccessarily follow that the engine is incapable of handling that level, put those textures into the unreal engine, and you'd get pretty much the same results, only with too much specular.
(...)but it's just possible that the people using Irrlicht are programmers first and can't afford Epic's art department.
I'm not saying it does, but when someone starts saying engine X is more awesome than engine Y while engine X hasn't been used to the extent engine Y has, it irks me somewhat.
As for the card itself, from what I understand, the data has to be processed outside the card and transmitted to it in a specific format, usually in 2 Meg chunks (iirc). The difference in time between rendering a 512 texture and a 64 texture is more or less immaterial, whereas the time required to transmit the two textures to the card itself is exactly the same. You might be able to transmit more textures in the 2 Meg chunk if using 64 x 64 but I'm pretty sure there are added complications to that as well.
The thing is, most Graphics cards are optimised for larger textures (256, 512 and 1024) and tend to work best using those sized textures.
It depends on a great deal of many things. The TMUs, the bus, etc...
-
Those newer cards are fast enough to make the point of engine speed pointless. And besides, if you are using the same textures (a 64x64 and a 512x512) to cover the same area, the 64x64 is going to be faster.
Wrong, wrong, wrongwrongwrongwrongwrongwrong WRONG.
First off, this mindset of "oh computers are so fast we don't have to worry about optimizing our code anymore!" is going to go down in flames once people realize how much power is being wasted on idiotic programming and wasteful resource use. This is best explained with an example that I found in my own efforts to optimize my engine: a month ago, my engine could render 10000 batch rendered images on my desktop at about 40 FPS. A short while later, I realized that I could massively optimize my rendering pipeline using a red-black linked list binary tree, as opposed to a sorted list. After a few other optimizations, the end result was that it can now render 10000 batch rendered images at 80 FPS.
By increasing the speed and efficiency of my engine, I doubled the speed of my rendering. Are you still telling me that engine speed is pointless?
Furthermore, smaller textures do not equate faster drawing. Almost the only thing that matters is how many pixels you are drawing to. If you have a 64x64 writing to the entire screen instead of a 256x256 writing to the entire screen, you have the same number of texture lookups going through a filtering process, which means your only benefit is memory: the lookups will be slightly faster for 64x64 because there's less memory to worry about.
This also,means that Flipside is somewhat mistaken: Large texture sizes are extremely dangerous. Case in point: If you put a 1024x1024 on my laptop, performance drops a significant amount. If you try putting a 2048x2048, it suffers catastrophic performance loss. Anything larger and it can't support it. However, render a 1024x1024 as 4 512x512 chunks, and you'll get a 20-30% performance increase. This same effect can be observed on my desktop, with its newer graphics card, at double that resolution - put in a 4096x4096 and it will start to suffocate. Do the same thing with 1024x1024 chunks and you'll get massive performance increases (in this case the textures have to be scaled back in size so they are all still rendering, otherwise the performance increase is due to culling. Note that the comparison here is between a 25% size 2048x2048 with 25% sized 1024x1024 chunks).
I'm not saying it does, but when someone starts saying engine X is more awesome than engine Y while engine X hasn't been used to the extent engine Y has, it irks me somewhat.
Windows is used everywhere. Do you think windows is awesome? Linux is only used by 2% of the computer population. That must mean it sucks, right? I don't think i need to really keep going here to point out the glaring flaw in your argument. Take Flash - Flash is a horrible monstrosity of bloated crapware that is so prevalent across the web because its only competitor is Microsoft's pathetic "silverlight" initiative. If you don't believe me that flash is crap, it takes the same amount of resources to run unoptimized flash games as it does to run Crysis. If you still don't believe me, flash once managed to crash my friend's computer and corrupt its own update file so that the system BSOD's every time he logged in. He had to go into safe mode and uninstall all adobe-related software just to get the thing functional again. This is the same program that is used on 99% of the websites across the web. Are you still, honest to god, telling me that just because X is used more then Y that Y can't be better then X?
Irrlicht's engine core is the best core I've ever seen. Just because its not focused on making everything pretty for the general public idiots doesn't mean its a piece of crap, it just means it has a different focus - speed. I'm sorry, but not everyone on the planet wants to buy a gaming rig that's the same price as a used car when modern graphics shouldn't be so goddamn bloated in the first place.
-
I have PC experience dating back to DOS 5 on intel 286 and things haven't changed you always need to run things in as close to optimum way as possible in terms of processor and memory because at the end of the day the potential for software always exceeds hardware capability, also remember in terms of implementation in FSO is that not everyone is running up-to-date kit, for example my machine is a 5-6 year old first gen Athlon 64 on the first mobo to use the nf 3 chipset, 1GB memory and GF 6600 GT, so a performance intensive graphics overlay on some of the inefficiency in FS (eg collision detection) would probably make the game close unplayable
-
There is also other factors included, like bsp spaces and culling that would probably make the unreal engine better than the open source (not that they couldn't they probably don't have the manpower).
-
There is also other factors included, like bsp spaces and culling that would probably make the unreal engine better than the open source (not that they couldn't they probably don't have the manpower).
Yes, but the point here was, which engine would you want to use to implement postprocessing in FS2? Having 1500 dependencies on other engine components isn't going to be much of a help. People look at Unreal and they're like OH YEAH LETS REVERSE ENGINEER THAT SO WE CAN HAVE PRETTY GRAPHICS TOO! The entire point here is that it's a misconception - there are better resources to implement this stuff in that will tell you what you actually need to do without being dependent on a gigantic huge engine library. Looking to a big fat bloated engine to implement features is always a bad idea, regardless of which engine or what features.
-
I don't think he meant the prevalence of engine X vs engine Y, I think he meant the extent to which its boundaries have been pushed. Other than that, good arguments Blackhole.
-
There is also other factors included, like bsp spaces and culling that would probably make the unreal engine better than the open source (not that they couldn't they probably don't have the manpower).
Yes, but the point here was, which engine would you want to use to implement postprocessing in FS2? Having 1500 dependencies on other engine components isn't going to be much of a help. People look at Unreal and they're like OH YEAH LETS REVERSE ENGINEER THAT SO WE CAN HAVE PRETTY GRAPHICS TOO! The entire point here is that it's a misconception - there are better resources to implement this stuff in that will tell you what you actually need to do without being dependent on a gigantic huge engine library. Looking to a big fat bloated engine to implement features is always a bad idea, regardless of which engine or what features.
FS2 wouldn't be a good use for the unreal engine, and the fs2 engine wouldn't be a good first person engine.
-
My school's computer club is going to flip when they find out about this.
-
I've gotta go with Blackhole. I can generally tell if the game is running on the Unreal engine the moment I get into gameplay. The graphics have an ... I dunno, an "Unreal" aura.
And he's also right. Smaller textures don't mean faster load times, and optimization will always be necessary. Sure you could run that program just fine on current PCs, no matter how crapsack its programming is. But optimize it, and it'll positively fly.
-
I can generally tell if the game is running on the Unreal engine the moment I get into gameplay. The graphics have an ... I dunno, an "Unreal" aura.
I guess I know I'm not alone now.
Though I'm not always correct in guessing if game X or game Y uses UE3... XD
-
Those newer cards are fast enough to make the point of engine speed pointless. And besides, if you are using the same textures (a 64x64 and a 512x512) to cover the same area, the 64x64 is going to be faster.
Wrong, wrong, wrongwrongwrongwrongwrongwrong WRONG.
First off, this mindset of "oh computers are so fast we don't have to worry about optimizing our code anymore!" is going to go down in flames once people realize how much power is being wasted on idiotic programming and wasteful resource use. This is best explained with an example that I found in my own efforts to optimize my engine: a month ago, my engine could render 10000 batch rendered images on my desktop at about 40 FPS. A short while later, I realized that I could massively optimize my rendering pipeline using a red-black linked list binary tree, as opposed to a sorted list. After a few other optimizations, the end result was that it can now render 10000 batch rendered images at 80 FPS.
Great, start programming in assembly then. Cause you know, there are a lot of cycles being wasted by compilers. C, C++, JAVA, Python, etc... all these? Wasting cycles by virtue of compilers not being perfect.
By increasing the speed and efficiency of my engine, I doubled the speed of my rendering. Are you still telling me that engine speed is pointless?
You are taking what I said and applying in a way I didn't mean to. When you have a newer card capable of rendering what the engine tells it at a ludicrous number of FPS, let's say for discussion sake's 300FPS minimum, while another engine only achieves a paultry 250 FPS also minimum. Does engine speed matter any more? Especially seing more screens nowadays can't output more than 60 Hz at their native resolution? When the human eye can't process information beyond 30 FPS? Does it really matter?
Furthermore, smaller textures do not equate faster drawing. Almost the only thing that matters is how many pixels you are drawing to. If you have a 64x64 writing to the entire screen instead of a 256x256 writing to the entire screen, you have the same number of texture lookups going through a filtering process, which means your only benefit is memory: the lookups will be slightly faster for 64x64 because there's less memory to worry about.
This also,means that Flipside is somewhat mistaken: Large texture sizes are extremely dangerous. Case in point: If you put a 1024x1024 on my laptop, performance drops a significant amount. If you try putting a 2048x2048, it suffers catastrophic performance loss. Anything larger and it can't support it. However, render a 1024x1024 as 4 512x512 chunks, and you'll get a 20-30% performance increase. This same effect can be observed on my desktop, with its newer graphics card, at double that resolution - put in a 4096x4096 and it will start to suffocate. Do the same thing with 1024x1024 chunks and you'll get massive performance increases (in this case the textures have to be scaled back in size so they are all still rendering, otherwise the performance increase is due to culling. Note that the comparison here is between a 25% size 2048x2048 with 25% sized 1024x1024 chunks).
I'm sure it doesn't automatically equate to faster drawing with a few oddball cases out there, but from the gist of things, you seem to agree with me. You only provided cases where the smaller resolutions are faster than larger resolutions.
I'm not saying it does, but when someone starts saying engine X is more awesome than engine Y while engine X hasn't been used to the extent engine Y has, it irks me somewhat.
Windows is used everywhere. Do you think windows is awesome? Linux is only used by 2% of the computer population. That must mean it sucks, right? I don't think i need to really keep going here to point out the glaring flaw in your argument. Take Flash - Flash is a horrible monstrosity of bloated crapware that is so prevalent across the web because its only competitor is Microsoft's pathetic "silverlight" initiative. If you don't believe me that flash is crap, it takes the same amount of resources to run unoptimized flash games as it does to run Crysis. If you still don't believe me, flash once managed to crash my friend's computer and corrupt its own update file so that the system BSOD's every time he logged in. He had to go into safe mode and uninstall all adobe-related software just to get the thing functional again. This is the same program that is used on 99% of the websites across the web. Are you still, honest to god, telling me that just because X is used more then Y that Y can't be better then X?
Used to the extent != popularity
Used to the extent == taking the engine further to the limit of what it can do.
Irrlicht's engine core is the best core I've ever seen. Just because its not focused on making everything pretty for the general public idiots doesn't mean its a piece of crap, it just means it has a different focus - speed. I'm sorry, but not everyone on the planet wants to buy a gaming rig that's the same price as a used car when modern graphics shouldn't be so goddamn bloated in the first place.
Maybe if Irrlicht had ways to make it easy to do the things the Unreal engine does easily or automatically, it would have more users. And until you use textures and models on par with the ones the Unreal engine uses, I'm not sure if you can make the assumption it would be faster. Hence my previous "used to the extent" remark. :P
Like the point I made in the beginning, why doesn't anyone but driver programmers and other lowlevel programmers use assembly anymore, despite enabling to waste less cycles? :P
-
It doesn't matter anyway because if anyone here has actually read the article and license terms, it says that the source is not released with this.
You can, however, make commercial games with it. Epic gets 25% on any profit over $5,000 though.
-
Ghostavo, yes engine speed still matters. You may not notice in the case you described, but when you actually start pushing the limits of the engine one will obviously choke before the other. Or what if you decide to use the engine to prerender frames? The faster engine will complete the task faster, significantly faster even. If you can optimize something with a little effort, it's probably worth it in the long run. But that's not saying that you should make design decisions that make it harder to maintain for the sake of efficiency, although in some cases that is still necessary (real-time programming for example).
-
What about when the decisions you make start lowering the effective ease of using an engine? Speed only matters if you can use it effectively. If the engine is too difficult to use with "modern graphic settings" (take that as you will) it's not a good engine to use in those cases.
-
Nobody's saying that either. Modern computing virtually necessitates some speed sacrifices to be made for ease of use, security, and maintainability of code. That doesn't excuse sloppy programming or wasting cycles 'because you can'. Suppose we end up with a model of computing-as-a-service, where you pay for usage of a cloud. Now let's say you pay for how much load you incur on a cluster. Obviously the cluster has the power to run any number of engines, but the most efficient one would be the one that costs you the least. Or when software designed for a certain environment needs to be ported to run on a much weaker infrastructure (say, running JS on a handheld device). Or, to stay on the Javascript example, look at how much more prevalent Javascript is. The pure speed of the Javascript engine is now becoming a factor in what browser many people are using nowadays (Apple Webkit/Chrome is kicking everyone's ass btw). The functionality of JS is the same across browsers, yet IE's engine sucks, Mozilla's is ok and Webkit puts them all to shame. Because they made an engine that can run it the fastest. If more energy had been put into a fast JS engine by the Firefox team earlier on they wouldn't be as far behind already as they are now. And Microsoft should just give up, their current engine probably needs a complete rewrite to stand a chance. Yet they're all the same ease of use because they're all a standard implementation.
-
Great, start programming in assembly then. Cause you know, there are a lot of cycles being wasted by compilers. C, C++, JAVA, Python, etc... all these? Wasting cycles by virtue of compilers not being perfect.
I actually do program my pixel shaders in assembly. The point I'm making here, however, is not that we need to rescue every last cycle that's being wasted by compilers, but to fix the idiotic programming mistakes that waste hundreds of thousands of cycles. The number of wasted cycles caused by imperfect compilers is several orders of magnitude smaller then the wasted cycles caused by stupid and/or lazy programming. THAT'S what I'm getting at here.
You are taking what I said and applying in a way I didn't mean to. When you have a newer card capable of rendering what the engine tells it at a ludicrous number of FPS, let's say for discussion sake's 300FPS minimum, while another engine only achieves a paultry 250 FPS also minimum. Does engine speed matter any more? Especially seing more screens nowadays can't output more than 60 Hz at their native resolution? When the human eye can't process information beyond 30 FPS? Does it really matter?
If that's true, you have no argument. No one here is arguing that a 10 year old game will not benefit from code optimizations on modern hardware. That's kind of a "No Duh" kind of thing. The only place that code optimization ever does become relevent is in cutting-edge software or software that takes up a significant amount of system resources. If your game is being rendered at 250 FPS, not only is it not taking up a significant amount of system resources, its actually wasting them, because you don't need to render above 60 FPS, and so you should be giving back the extra CPU cycles you don't need to the system instead of hogging them. For the sake of the rest of this post I will assume we are talking about modern games instead of pac-man.
I'm sure it doesn't automatically equate to faster drawing with a few oddball cases out there, but from the gist of things, you seem to agree with me. You only provided cases where the smaller resolutions are faster than larger resolutions.
Oh I am agreeing with you. Smaller textures do allow for faster rendering... just not by much.
Maybe if Irrlicht had ways to make it easy to do the things the Unreal engine does easily or automatically, it would have more users. And until you use textures and models on par with the ones the Unreal engine uses, I'm not sure if you can make the assumption it would be faster. Hence my previous "used to the extent" remark.
I can't make any argument against this without hard data, and I really don't have time to set up benchmarks just to prove a point, so I'll just leave this one for another day.
Like the point I made in the beginning, why doesn't anyone but driver programmers and other lowlevel programmers use assembly anymore, despite enabling to waste less cycles?
And like the point I made in the beginning, its not a matter of wasting a few CPU cycles, its a matter of inherently bad and lazy programming that wastes millions of cycles and hundreds of megabytes of memory. As I mentioned before, doing a small optimization like switching from a linked list to an optimized binary tree (which no one even has to code themselves) can result in massive performance increases.
What about when the decisions you make start lowering the effective ease of using an engine? Speed only matters if you can use it effectively. If the engine is too difficult to use with "modern graphic settings" (take that as you will) it's not a good engine to use in those cases.
96% of the time, it is possible to optimize an engine in such a way that its ease of use is not affected. Furthermore, I have a counterexample: My graphics engine does both at the same time. In an effort to make it easier for the programmer, it automatically sorts and optimizes every single image in its rendering pipeline. By doing this through a highly efficient pipeline, it actually improves the average performance of the application because the programmer is no longer required to figure out all possible optimizations anymore - the engine does it instead.
My fundamental point here is that modern applications are bloated and slow and bog down machines when there exist proven examples of programs that do the exact same thing at a fraction of the cost. Lazy programming helps no one.
-
Quite simply, Ghostavo, optimization is important, because its the engine that matters the most for graphics and the like, not the texture sizes. Optimization is becoming more and more neccessary, regardless.
-
I can't tell what exactly you guys are arguing about. :p Engine optimization is obviously important, but UE3 is quite well optimized. As I said earlier, games like UT3 run well on a range of hardware.
And large textures make a huge difference to image quality. However, there are very few modern games that actually use large textures, as the consoles can't handle them. The best use of consistently large textures I've seen is in the original UT with the S3TC packages (the textures are actually for Unreal 1, which can be played through UT). Some of them go up to 4096x4096 and look fantastic, especially combined with the engine's multi-layered detail texturing.
-
I can't tell what exactly you guys are arguing about. :p Engine optimization is obviously important, but UE3 is quite well optimized. As I said earlier, games like UT3 run well on a range of hardware.
And large textures make a huge difference to image quality. However, there are very few modern games that actually use large textures, as the consoles can't handle them. The best use of consistently large textures I've seen is in the original UT with the S3TC packages (the textures are actually for Unreal 1, which can be played through UT). Some of them go up to 4096x4096 and look fantastic, especially combined with the engine's multi-layered detail texturing.
the engine's texturing often looks not that nice, especially scaled back, IMO, but that's mainly from playing UT3, AA3 on it.
-
I can't tell what exactly you guys are arguing about. :p Engine optimization is obviously important, but UE3 is quite well optimized. As I said earlier, games like UT3 run well on a range of hardware.
As far as I could tell, it was about the importance of optimization in relation to the increasing power of processors as well as the potential to reverse engineer the UE for FSO
-
Showed t his to my buddy Dan today (huge UE fan), he had a comment or two:
[10:54] Dan: Also, graphics engines impose a given look and feel on all the games that they render based on how they do things. Unreal is powerful, but its still based around a whole bunch of largely fixed-function ideas, like skyboxes.
[10:54] Dan: WRONG
[10:54] Dan: ue3 does not do skyboxes
[10:54] Dan: it also, has subtractive/additive map modes
[10:55] Dan: which was a new feature to ue
-
Is... is he arguing with himself? :nervous:
-
That first line was a quote from earlier.
-
Showed t his to my buddy Dan today (huge UE fan), he had a comment or two:
[10:54] Dan: Also, graphics engines impose a given look and feel on all the games that they render based on how they do things. Unreal is powerful, but its still based around a whole bunch of largely fixed-function ideas, like skyboxes.
[10:54] Dan: WRONG
[10:54] Dan: ue3 does not do skyboxes
[10:54] Dan: it also, has subtractive/additive map modes
[10:55] Dan: which was a new feature to ue
Strange, I could've sworn UE3 used skyboxes for some reason - but I looked it up, and it uses static mesh skyboxes.
Of course, even with those, it still doesn't invalidate my point :P
Also, your buddy is going to hate me in about 3 years.
-
hmmm, random tangent here what about the HL1 engine?
-
You mean the highly modified hacked up Quake 1 engine with some fixes backported from Q2, otherwise known as GoldSrc? I was already saying, the original Unreal engine blew it out of the water in terms of appearance, and performance in Glide was amazing compared to HL1 in OpenGL.
-
I'm not sure what the pros and cons of the different types of skyboxes are, but UT3 has a couple of unusual skyboxes, especially in the Necris themed maps. Even the first Unreal engine could do some interesting things with the skybox. One example is the Versalife level in Deus Ex, where the skybox contains NPCs walking around outside.
the engine's texturing often looks not that nice, especially scaled back, IMO, but that's mainly from playing UT3, AA3 on it.
UT3's textures are generally very good and better than most games out there, but are not entirely consistent. A lot of other games built on the UE3 engine have crappy textures though. Bioshock is an especially big example of this.
-
Actually there's one very prominent reason why unreal games have an "unreal" feel to them, and that is because game developers abuse the everloving crap out of that stupid bloom shader.
-
That and weapons defy all rules of realism. :P
-
As I've said before, bloom, the new lensflare. :p
-
Actually there's one very prominent reason why unreal games have an "unreal" feel to them, and that is because game developers abuse the everloving crap out of that stupid bloom shader.
This is true. The R6 Vegas games come to mind, and Mass Effect in some places was pretty bad too. It's an issue in many modern games in general.
UT3's bloom is more reasonable. A lot of maps have a kind of "foggy" effect that looks strange, but the level of bloom is generally where it should be.
That and weapons defy all rules of realism.
That may be a good thing, depending on what the game is supposed to be like. I certainly wouldn't want realistic weapons in UT3. :p
-
Any Unreal game as blackhole said. :D
Plus UT3 has an adjustable bloom setting.
-
UT3's bloom is more reasonable. A lot of maps have a kind of "foggy" effect that looks strange, but the level of bloom is generally where it should be.
The level of bloom will be where it should be when it's turned off.
-
UT3's bloom is more reasonable. A lot of maps have a kind of "foggy" effect that looks strange, but the level of bloom is generally where it should be.
The level of bloom will be where it should be when it's turned off.
I like to have some amount of bloom, mainly around light sources. We don't yet have HDR monitors that can show lights properly, and bloom is a reasonable substitute for giving the impression of brightness.
-
UT3's bloom is more reasonable. A lot of maps have a kind of "foggy" effect that looks strange, but the level of bloom is generally where it should be.
The level of bloom will be where it should be when it's turned off.
I like to have some amount of bloom, mainly around light sources. We don't yet have HDR monitors that can show lights properly, and bloom is a reasonable substitute for giving the impression of brightness.
Wrong.
I have done studies of this in my own personal time, and bloom occurs naturally only in certain circumstances where there is a large contrast between the current ambient light in a given room and the light source in question. This means that it only occurs indoors and at night under extreme contrast differences. If you are outside in the day, you should never, ever, ever see any bloom of any sort because there is not enough contrast. You are correct that it should appear around light sources, but it really should only appear around light sources and/or extremely reflective surfaces. It is also a LOT more subtle in real-life.
When you look at the sun or another bright object and it appears "very bright", the reason for this is not because of bloom, but rather of a phenomenon that I've called "light-bleeding." The easiest way to observe this is to look at the sun through a bunch of trees. If you compare the holes in the trees to the holes in a group of similar trees in the opposite direction, the amount of perceived light that's filtering through the sun-facing ones is larger then the hole should actually permit. This has to do with light scattering and a bunch of other techno-crap, but the point being that if something is very, very bright, in a 3D renderer's point of view it should "bleed through" the nearest opaque pixels. (this effect can be achieved via the manipulation of HDR textures in a single pass, without any sort of filtering). This is what gives us the perception that something is very very bright, not bloom. Bloom is simply an artifact of imperfections in our eyes (the drier your eyes are, the less bloom you'll see).
This is even further confounded by the fact that games aren't even using HDR like they should be using it. Real HDR photography is the art of taking pictures of a scene with a lot of contrast and allowing the darker areas to show up against the brighter ones, which mimics our own brain's filtering process IRL. Games use this "HDR" simply to move the average light value up or down, without ever actually increasing the range of lighting that the monitor is representing. This could be fixed with a GPU-based HDR spectrum analysis.
Games will be able to say they're using HDR rendering when they look like this:
(http://upload.wikimedia.org/wikipedia/commons/0/09/Hdr-Ithacafalls2.jpg)
-
I think bloom can look pretty when employed artistically.
-
Not being up on modern game engines, one thing that astounded me when I tried out the Half-Life 2 Lost Coast tech demo was the "light overload" feature they had implemented via some sort of HDR usage. When you looked up at the sun or walked out of a dark room, your vision got all washed out for a few seconds, just like looking at a bright light source in real life, and the reverse was true when walking indoors. I didn't get to see it at work during the actual episodes, since I couldn't have HDR enabled and get any sort of playable framerate on this machine, but it was an impressive little trick regardless.
-
Wrong.
I have done studies of this in my own personal time, and bloom occurs naturally only in certain circumstances where there is a large contrast between the current ambient light in a given room and the light source in question. This means that it only occurs indoors and at night under extreme contrast differences. If you are outside in the day, you should never, ever, ever see any bloom of any sort because there is not enough contrast. You are correct that it should appear around light sources, but it really should only appear around light sources and/or extremely reflective surfaces. It is also a LOT more subtle in real-life.
Obviously, my post went over your head. I didn't say that we see any bloom in real life, but that bloom in games simply gives a subjective impression of high brightness. I'm thinking of it as more of an artistic effect than anything else. The actual brightness of the bloomed object is going to be limited by your monitor.
We can't do any better than bloom right now because true HDR is impossible on current consumer monitors. For that, we need displays that support 10 or 12 bit color modes along with a much higher top brightness. The only displays that do this right now are $10k+ professional and medical models. What games with HDR currently do is called tone mapping, which does internal lighting calculations in HDR (floating-point, specifically) but maps the result into the monitor's 8 bit integer dynamic range. The mapping is weighted using a form of average light level, in basically the manner you described.
-
Couldn't light fog cause hdr in real-life?
-
We can't do any better than bloom right now
Saying that this isn't true was kind of the entire point of my post :P
-
We can't do any better than bloom right now
Saying that this isn't true was kind of the entire point of my post :P
Making the surrounding areas darker is not HDR at all and is not going to make lights look any brighter. It's true that our eyes experience different levels of brightness based on nearby contrast, but consumer LCDs in typical ambient light conditions don't come anywhere close to showing the level of contrast we see in real life.
Basically, the displays are the real bottleneck with this, not the game engines.
-
Making the surrounding areas darker is not HDR at all and is not going to make lights look any brighter. It's true that our eyes experience different levels of brightness based on nearby contrast, but consumer LCDs in typical ambient light conditions don't come anywhere close to showing the level of contrast we see in real life.
Basically, the displays are the real bottleneck with this, not the game engines.
No, they aren't. Making the surrounding areas darker is the exact opposite of what i was describing and is basically what consumer games do nowadays, so i'm not entirely sure what you mean by that. But the simple fact that this image (http://theautochthon.files.wordpress.com/2009/07/hdr.jpg) can exist on my moniter, combined with the fact that crysis looks like this (http://www.thekoalition.com/wp-content/uploads/2009/06/crysis068.jpg), proves that yes, there is a dynamic range available in LCDs that is not being utilized. Sure, crysis has pretty graphics, but all its managed to do is look like a low-contrast photograph with half its colors saturated out. There is more potential here.
-
What you said was this:
Real HDR photography is the art of taking pictures of a scene with a lot of contrast and allowing the darker areas to show up against the brighter ones, which mimics our own brain's filtering process IRL.
This can be done but the image still has to be tone mapped in the end because of the limited dynamic range of the display, which means you're going to wash out dark details somewhere.
As for the examples you posted, the dynamic range is the same in both images. They both go from black to white (more or less) on an 8-bit color space. I do like the colors and art in the "HDR" image, but the sun on the horizon is the only light source and it doesn't look very bright at all.
-
This can be done but the image still has to be tone mapped in the end because of the limited dynamic range of the display, which means you're going to wash out dark details somewhere.
This is correct. My point here being that the limited range of the display is not the only limiting factor here.
As for the examples you posted, the dynamic range is the same in both images. They both go from black to white (more or less) on an 8-bit color space. I do like the colors and art in the "HDR" image, but the sun on the horizon is the only light source and it doesn't look very bright at all.
The actual dynamic range is the same, yes, but the effective range of colors is far greater and the scene looks much more interesting and less washed out. There is a difference between having a range of colors in an 8-bit color space and actually using the entire available spectrum.
Also, apparently you have never photographed a sunset :P That sun is goddamned bright, even if its not directly in the picture.
-
The picture is certainly more vibrant but that doesn't affect the look of the light source, which is the main point of discussion here. I'm not contesting the fact that the picture looks better overall, only that the light source in it doesn't look very bright.
That sun is goddamned bright, even if its not directly in the picture.
Are you talking about a real sunset or the one in that picture? :p The one in the picture does not look "goddamned bright" to me compared to an actual sunset in real life, and this is necessarily a limitation of the display (as well as the room lighting for most people).
In fact, looking at the picture more closely shows a small amount of bloom around that area. I think that is the main thing giving it any impression of brightness at all.
-
The one in the picture does not look "goddamned bright" to me compared to an actual sunset in real life, and this is necessarily a limitation of the display (as well as the room lighting for most people).
To me, the sunset in the picture looks very bright, and yes, you are correct that there is subtle bloom going on there as well, along with many other things. But I don't understand how it doesn't seem very bright to you. You seem to want it to be as bright as a REAL sunset, and that would just burn our eyeballs out :P
-
It obviously shouldn't be as bright as the real thing, but it needs to be much brighter than what current displays can do. (but at the same time, I don't want everything to look that bright, hence the need for more than 8-bit color input)
My CRT does around 400 nits with ideal blacks, and even with the lights off I still wouldn't say that sunset looks bright. Something with a higher brightness (like 1000+ nits) but based on an emissive technology, maybe some kind of OLED, might produce a better effect. As it stands, the bloomed Crysis explosion gives a better "feel" of brightness to me, even though it's not actually any brighter.
Look up the Brightside DR37-P. It was an HDR LCD that was little more than a proof of concept, but it went up to 4000 nits and had individual LEDs for backlighting, so it could show true blacks as well. We need to see more stuff like that, and at more reasonable prices.
-
It obviously shouldn't be as bright as the real thing, but it needs to be much brighter than what current displays can do. (but at the same time, I don't want everything to look that bright, hence the need for more than 8-bit color input)
My CRT does around 400 nits with ideal blacks, and even with the lights off I still wouldn't say that sunset looks bright. Something with a higher brightness (like 1000+ nits) but based on an emissive technology, maybe some kind of OLED, might produce a better effect. As it stands, the bloomed Crysis explosion gives a better "feel" of brightness to me, even though it's not actually any brighter.
Look up the Brightside DR37-P. It was an HDR LCD that was little more than a proof of concept, but it went up to 4000 nits and had individual LEDs for backlighting, so it could show true blacks as well. We need to see more stuff like that, and at more reasonable prices.
I am strongly against this. I currently have my monitors brightness down to the lowest it can possibly be without sacrificing contrast, and that sunset still feels "bright" to me and I certainly don't want my monitor to be brighter then what it already is. What I think your referring to here is the contrast ratio, not how bright moniters can get (because monitors can be made to be painfully bright). The true blacks part is what allows for high constrast ratios, which is what allows HD-TVs to be HD.
I still say that there are far better and more subtle methods of making things appear "bright" then just farting out a bloom shader which simply degrades image quality.
-
Yeah, I should have elaborated on that further. I want displays that can look bright while still maintaining a good black level. Many current LCDs can in fact go to 1000 or 1500 nits, but the blacks will look very poor at anything beyond about 300 nits.
You probably have the brightness turned down to have Windows look comfortable. I do that too. The whole point of an HDR input mode is that the high brightness is only used for colors outside the 8-bit dynamic range, while normal 8-bit content is shown with much lower (maybe 200-ish) top brightness.
Bloom can be done right. It's just that most games that use it go overboard with it.
-
That sunset picture is awesome. :P
-
You probably have the brightness turned down to have Windows look comfortable. I do that too. The whole point of an HDR input mode is that the high brightness is only used for colors outside the 8-bit dynamic range, while normal 8-bit content is shown with much lower (maybe 200-ish) top brightness.
Again, I would be careful with this. Going over the normal brightness of a monitor, even if its just for a single light source, could be potentially dangerous to our vision. As if staring at an LCD all day isn't bad enough, now we're staring at an LCD that can, without warning, decide that a picture is HDR and show something that's like 2 times as bright as normal. The problem is that even if normal 8bit stuff is shown at reduced brightness, we'll get used to this, turn up the brightness on the monitor to compensate, then go look at an HDR picture and be like "My eyes! They burn!" :P
Bloom can be done right. It's just that most games that use it go overboard with it.
The problem is that for bloom to be done right, it loses part of its ability to make things appear bright in the first place, which is where the primary phenomena of light bleeding comes into play.
-
OLED solves a lot of this.
-
Again, I would be careful with this. Going over the normal brightness of a monitor, even if its just for a single light source, could be potentially dangerous to our vision. As if staring at an LCD all day isn't bad enough, now we're staring at an LCD that can, without warning, decide that a picture is HDR and show something that's like 2 times as bright as normal. The problem is that even if normal 8bit stuff is shown at reduced brightness, we'll get used to this, turn up the brightness on the monitor to compensate, then go look at an HDR picture and be like "My eyes! They burn!"
The brightness changes we're talking about are nowhere near a point where they would cause damage to our eyes. Just looking outside a window on a sunny day is a much greater increase in the brightness of our viewed image than anything a monitor could produce.
The problem is that for bloom to be done right, it loses part of its ability to make things appear bright in the first place, which is where the primary phenomena of light bleeding comes into play.
The point is to achieve a balance between those extremes. Most games go overboard with it, but there are a couple of games that I think have done it right.
OLED solves a lot of this.
:yes:
-
This is possibly one of the more civil yet still heated discussions to take place yet.
.... Carry on, the two of you.
-
The brightness changes we're talking about are nowhere near a point where they would cause damage to our eyes. Just looking outside a window on a sunny day is a much greater increase in the brightness of our viewed image than anything a monitor could produce.
No but they might still be annoying :P. Again i think its just a matter of contrast ratio so its something of a mute point. The monitors will do what the monitors will do and whichever one is least annoying everyone will start buying.
The point is to achieve a balance between those extremes. Most games go overboard with it, but there are a couple of games that I think have done it right.
I think there's a distinction between acceptable and right. While I concur that some games have had acceptable amounts of bloom, I would argue that vanishingly few, if any, have actually gotten it right, mostly because getting bloom "right" is extremely difficult and requires deep HDR analysis.
OLED solves a lot of this.
The one question I have about OLED is if we'll need more then 32 bits of color to accurately use it. Perhaps we'll move to 64 bits of color along with the natural processor movement to 64-bit architecture?
-
Nah man, you won't need that. As it is, most LCDs can't properly display #000000 and #FFFFFF at the same time. The backlight washes out the #000000 and turns it to a grey, or you turn the brightness down and end up with a dim #FFFFFF. An OLED will be able to do that properly though, and show you the full range, since it has no backlight.
-
Nah man, you won't need that. As it is, most LCDs can't properly display #000000 and #FFFFFF at the same time. The backlight washes out the #000000 and turns it to a grey, or you turn the brightness down and end up with a dim #FFFFFF. An OLED will be able to do that properly though, and show you the full range, since it has no backlight.
So why doesn't some hardware genius hurry up and invent cheap OLEDs? :P
-
Bigger problem, last I heard, was still the lifespan of the OLEDs themselves. They're not quite up to snuff yet I think. But they've made a lot of breakthroughs in this area in the last year or so.
-
I think there's a distinction between acceptable and right. While I concur that some games have had acceptable amounts of bloom, I would argue that vanishingly few, if any, have actually gotten it right, mostly because getting bloom "right" is extremely difficult and requires deep HDR analysis.
It depends on your basis for comparison. I'm comparing them to old games that did not have any bloom at all, not high quality renders.
Bigger problem, last I heard, was still the lifespan of the OLEDs themselves. They're not quite up to snuff yet I think. But they've made a lot of breakthroughs in this area in the last year or so.
The problem with the blue lifespan was apparently solved quite some time ago, at least on lab prototypes. Unfortunately, it seems like we're not going to see any mass-produced models until 2012. :blah:
OLEDs will have numerous other advantages over LCDs, even if we don't see them support any HDR color modes.
-
It depends on your basis for comparison. I'm comparing them to old games that did not have any bloom at all, not high quality renders.
I would argue that the only thing we should be comparing them to is Real Lifetm (or a hyper-realistic render that is somehow better then reality).
-
You would find just about all game graphics disappointing, in that case. :p
Also, it's not always desirable for game graphics to emulate real life. It depends on the nature of the game. For a game like UT3 for example, I would rather see something creative instead of having graphics that look exactly like real life.
-
Exactly, which is why Valve chose to go the way they did with Team Fortress 2, among various other examples.
-
I totally concur. I'd rather have pretty than realistic.
-
Also, it's not always desirable for game graphics to emulate real life. It depends on the nature of the game. For a game like UT3 for example, I would rather see something creative instead of having graphics that look exactly like real life.
That wasn't my point. My point is that for saying who has implemented what effect in the correct manner, you would want to compare it to real life. Nowhere did I say or imply that game graphics should mimic real life. However, in that regard, I do want to point out that if your going to have something look pretty, it takes almost as much graphics processing power as to make something look realistic, so if you make a graphics engine capable of rendering something that looks photorealistic, you will therefore also be able to so artistic things like TF2 and Okami.
-
Wtf is with this topic, this really didn't go down the way I expected it to. :sigh: Pointless topic is pointless.
-
Wtf is with this topic, this really didn't go down the way I expected it to. :sigh: Pointless topic is pointless.
Successful Hijack is Successful!
-
:lol:
While I'm at it.
However, in that regard, I do want to point out that if your going to have something look pretty, it takes almost as much graphics processing power as to make something look realistic, so if you make a graphics engine capable of rendering something that looks photorealistic, you will therefore also be able to so artistic things like TF2 and Okami.
What happens when the order is reversed, and to make photorealistic renders takes less effort than making what you want? Meaning, the lighting effects we have in real life become not a superset of those we use in gaming but a subset. :D
-
That wasn't my point. My point is that for saying who has implemented what effect in the correct manner, you would want to compare it to real life. Nowhere did I say or imply that game graphics should mimic real life. However, in that regard, I do want to point out that if your going to have something look pretty, it takes almost as much graphics processing power as to make something look realistic, so if you make a graphics engine capable of rendering something that looks photorealistic, you will therefore also be able to so artistic things like TF2 and Okami.
In terms of the GPU power needed, sure, but when it comes to specific effects like bloom, they don't necessarily go hand-in-hand anymore.
Wtf is with this topic, this really didn't go down the way I expected it to. Pointless topic is pointless.
We're having a great time here. :D
-
In terms of the GPU power needed, sure, but when it comes to specific effects like bloom, they don't necessarily go hand-in-hand anymore.
Ah, but all effects are by definition related to each other and therefore an optimized graphics engine that is good at one will (usually) be good at all of them. That is to say, if you build the necessary optimized framework to handle an arbitrary shader (which you'll have to do to get a photorealistic render), then you'll automatically improve the preformance of completely unrelated shaders. This is excluding the always-existent possibility of lazy programming and hard-coded shader implementations.
What happens when the order is reversed, and to make photorealistic renders takes less effort than making what you want? Meaning, the lighting effects we have in real life become not a superset of those we use in gaming but a subset.
I think for a lot of artistic effects, that is already true, especially for things like edge shading and whatnot. This usually goes away in combination with the lower texture resolution and other optimizations, though.
-
Ah, but all effects are by definition related to each other and therefore an optimized graphics engine that is good at one will (usually) be good at all of them. That is to say, if you build the necessary optimized framework to handle an arbitrary shader (which you'll have to do to get a photorealistic render), then you'll automatically improve the preformance of completely unrelated shaders. This is excluding the always-existent possibility of lazy programming and hard-coded shader implementations.
I'm simply referring to the intensity of a given effect, not the engine's support or lack of support for it. It would typically just be controlled by various parameters. My main point is that the "right" amount of bloom for a given game will depend on the kind of game it is.
-
Ah, but all effects are by definition related to each other and therefore an optimized graphics engine that is good at one will (usually) be good at all of them. That is to say, if you build the necessary optimized framework to handle an arbitrary shader (which you'll have to do to get a photorealistic render), then you'll automatically improve the preformance of completely unrelated shaders. This is excluding the always-existent possibility of lazy programming and hard-coded shader implementations.
I'm simply referring to the intensity of a given effect, not the engine's support or lack of support for it. It would typically just be controlled by various parameters. My main point is that the "right" amount of bloom for a given game will depend on the kind of game it is.
True. This, however, encroaches on the territory of when artistic expression starts to interfere with gameplay (http://www.vgcats.com/comics/?strip_id=224).