Those screens look pretty flat to me... I can't really see any shadows in most of the shots. I'm super excited, but deferred lighting, like CE3, is what I'm hoping for.
Like here, I see a shadow, hidden behind one of the planet things, but none on the ground. Because of this it just looks dated to me in most of these shots, to be honest- except for the Mountains. Those look pretty darn good.
EDIT: That new demon and mountain shot look so much better than before. Orb one still isnt impressive, but again, cant wait too see it in motion. Especially those practicals!
Really hopping that "Real Time Global Illumination" is what were seeing in those shots. But either way i'm very happy to see emmissive as lighting as an option.
Fancier graphics be damned if it means we still have to deal with seemingly random and absurd normal map and world lighting issues in an engine that is so heavily model-based that it shouldn't have had the issues in the first place.
Look better, but I'm curious what hardware we be needed to run it everything on consider it high settings (all fancy lighting like GI enabled) on average 40fps with full packed action.
The glossy surfaces on the planetarium scene look like they are using IBL GI similar to Cryengine 3... that's a little disappointing if it's true. I guess my expecations for RT-GI are a little high. I hope they they at least get some deferred LPVs or something similar to that real time voxel based method I posted in the video above for diffuse and glossy inter-reflection.
At this point I think its a given that there wont be baked lightmaps at the core of every level?
I believe the orb demo is to show off the near real-time c++ programming and compiling.
Yup:
This part was pretty interesting:
Hopefully this means its automatic and not just some pint light they attached to the hammer.
I hope cryengine lets us do this eventually. They got some interesting features in the cinema version of cry3 like area lights using LPVs, that would be cool too.
Sorry about my earlier comment about the pictures not being impressive.
Actually now that i've think of it, seeing those scenes realtime in a game.. it would be pretty awesome,
and the quality only gets better in the future.
The new shots are much better.
With them saying that there is a focus on improving the speed and efficiency of tools, I'm hoping some of that translates to them being inspired by Unity. UE3/UDK is no doubt very powerful, but its not the easiest engine to create new gameplay mechanics for.
I remember being blown away by it back in the day. Unreal Engine is one of the best, if not the best engine..overall that is. It's not just the graphics that make it so powerful, but sadly it's the easiest part to talk about, especially for gamers.
So I think one needs to be careful when comparing it other engines. Especially the ones who actually have to work with it, the artist is only a part of the team, Epic probably have lots of sweet stuff for programmers/techies/animators/sound-designers/network-engineers/etc. But the consumer only understands how good an engine is based on how much raw graphical power it has, it's always been like that.
Sorry if I generalized too much, anyways I'd like to know more about:
Is unrealscript still there? Did they change it? I'd love some c#'ish language, so that more poeple can jump right in.
What updates do the AnimTree/AnimSet editors have? Is there some kind of built-in locomotion system ( endorphin etc? ).
Is Mobile supported from the get go? If so, how does the new lighting system work on mobile, I assume it won't run. So in that case, the lightmap stuff must still be in the engine? If so, can I mix dynamic and static?
How about the actual editor, can I customize/extend it like Unity? Can I create my own windows/buttons/etc.
And there's probably a lot more interesting questions than: how many particles can it render?
I remember that demo at E3, and I thought whoa, cool. Very detailed.
But nothing i'm sorry surpasses the epic demonstration of Valve showing off Half-Life 2 and Source engine. That was a mind blowing timeline to be marked.
Is it just me... I think the Unreal 3 demo looks better. Sure, there's less (no) particles, no tesselation, but... I dunno. Maybe the U4 shots aren't lit in a certain way so they can show off the new features? Something is really throwing me off those screens. They look like pre-rendered FMV's from the 90's (but with more particles). And that 'solar system' screen doesn't help things much, it looks like 'my first maya project' to me.
I dunno. I'm sure the engine will be cutting edge. And I'm damn sure I don't understand most of the technology they are actually showing off. But it's hard to believe that this came from the same studio that made the samaritan demo, AFTER they made the samaritan demo, and not 15 years before (not talking in terms of tech, more, the style of the piece). My 2c.
The samaritan demo was created for gamers and consumers, this is a tech demo created for people that have used udk or similar tools, and can see what the new features are without being in a polished game with art direction context.
The samaritan demo was created for gamers and consumers, this is a tech demo created for people that have used udk or similar tools, and can see what the new features are without being in a polished game with art direction context.
What would be the purpose of this? Think the developers went all starry eyed over some bokeh and MSAA anti-aliasing when they saw the samaritan demo and stopped concentrating, so Epic pared it back a little for the next one? lol. I don't understand your point.
And also... demons in volcanoes? Seriously? That shit went out of fashion with Dungeon Keeper, seems like we're back in the 90's PC market days. :poly142: Wanna throw some particles around? Show me a storm chaser running around after hurricanes'n'shit man, some interesting story-telling ain't gonna hurt a tech demo, look at the Samaritan demo. That was tight. The demon in this demo looks like he should be on the cover art of a graphics card box. (No offence to any artists involved, just not personally feeling the design. Still scratching my head over how Epic could get it so so right with the Samaritan demo, then go with this)
But yeah. Looking forward to 'getting it' when I see the video come June!
This tech demo obviously has less time spent on the art, and more time on the features and actual engine. Story, art direction, and all that takes a lot of time, everything here looks feature oriented, no time was wasted on putting it into a video game context, besides "we can do a moutain range and big enviroments now!, and cool real time emissive lighting, crazy particals, real time compiling" etc.
Yeah I think this is probably the biggest focus of this, certainly reads like it from the article, unfortunately it goes right over my head :poly142: Not sure what's different about the previous lighting model; I guess running it from pure C++ makes it faster or more powerful I guess. Can anyone explain the differences in laymans terms? What makes this new way better?
Andreas, the idea is making everything much more realtime as instant feedback allows users to solve problems faster. For example with the lighting, you're not looking at a busted ass level the whole time you work on lighting only to compile and see some errors. With the programming, imagine having your game running, adjusting jump height, tab back over and the player is now jumping higher. As in, never leaving the game, seeing the code compile and sudden the change just takes effect.
Andreas, the idea is making everything much more realtime as instant feedback allows users to solve problems faster. For example with the lighting, you're not looking at a busted ass level the whole time you work on lighting only to compile and see some errors. With the programming, imagine having your game running, adjusting jump height, tab back over and the player is now jumping higher. As in, never leaving the game, seeing the code compile and sudden the change just takes effect.
Andreas, the idea is making everything much more realtime as instant feedback allows users to solve problems faster. For example with the lighting, you're not looking at a busted ass level the whole time you work on lighting only to compile and see some errors. With the programming, imagine having your game running, adjusting jump height, tab back over and the player is now jumping higher. As in, never leaving the game, seeing the code compile and sudden the change just takes effect.
Interesting. So no more 'Lighting needs to be rebuilt' warning?
So, any reasons why we are made to wait? "You gotta see this in action" is great and all, except we can't - so harsh pre-emptive judgements are made.
You just answered your own question. How else are we expected to go 'I WAS SO WRONG THIS IS GONNA CHANGE EVERYTHING!' and then start frothing at the mouth?
But really I imagine it has something to do with the companies relationship with companies like SONY and MS, and making developers they want to court feel special by showing them these things way ahead of the rest of the plebs. :thumbup:
Andreas, the idea is making everything much more realtime as instant feedback allows users to solve problems faster. For example with the lighting, you're not looking at a busted ass level the whole time you work on lighting only to compile and see some errors. With the programming, imagine having your game running, adjusting jump height, tab back over and the player is now jumping higher. As in, never leaving the game, seeing the code compile and sudden the change just takes effect.
FYI, you can already do this in UDK if your workflow doesn't suck. You have archetypes, ini files and console commands at your disposal.
But I do agree, iteration time for programming in UE3 is horrific. Make a native code change and you can be waiting for 3-4 minutes (15 minutes on a lower-spec machine) before you can even test it - if there are no compilation errors to deal with.
So fully dynamic lighting ? Not even baking indirect bounce lighting ?
I'm sure you could still do that. Performance is as major an issue as it has always been. I guess the point is that you have the capability to do it dynamically too now, if the scene/shot calls for it. But otherwise you'd probably still be better off baking it for performance reasons.
LOL ENGINES DONT MATTER CUZ GAMEPLAY GUYZ WHO NEEDZ GRAFIX, GAMEPLAY.
Hnnnnnnnng, I dunno, I need to see these in motion. Screenshot of anything simply haven't looked good this generation unless they were touched up afterwards or were taken in Prebaked Lighting: The Game, though those mountains and statues look very hot, love the materials and how good the lighting looks.
The other features sound pretty awesome though.. I haven't touched UE3 or UDK in ages, might just use this as a incentive to do things again.
Looks okay. In some of later sceenshots the textures look kind of blurry. I am glad UE4 in moving in the direction of dynamic lighting. Lightmass can be a pain in the azz. I also hope it fix normal seam issues.
Guys did any of you wonderd what will happen to AMD users ? Because you know, all these fancy effects are based on PhysX which is only accelarted by NVIDIA cards (of course there is no problem to port it for DirectCompute if.. anyone would be intrested in it..).
And moreover, that latests rumors says that next-gen consoles will be on AMD GPUs (at least I hope so, I'm all against single company monopoly).
AMD always had success with GPU's for monotone hardware based devices, like Consoles or anything in the 'small' scale of things.
It seems like nVidia will keep on dominating the 'tools of trade' area of things, because lets face it, they did the smart thing, which was strikes deals and work WITH those companies.
Of course I did. But you are missing my point. The fancy features we saw on screenshots (Particles, and I assume that flowing lava was fluid simulation), was based on PhysX (APEX). It's not something you can just unplug and plug another physics engine. Havok AFAIK do not even support fluid simulation.
It's just to deeply integrated within engine. I have feeling that Epic made very wrong decision here. Either for they or us (I hope it will be for them, as it's going to be lesser evil ;p).
Unless nvidia will finally stop using CUDA and port PhysX to DirectCompute.
The fancy features we saw on screenshots (Particles, and I assume that flowing lava was fluid simulation), was based on PhysX (APEX).
Source? I don't remember reading that anywhere... how do you know those aren't dedicated Unreal 4 features? Seems like they'd be showing those, considering they are promoting the Unreal 4 engine, rather than giving nVidia free advertising...
Source? I don't remember reading that anywhere... how do you know those aren't dedicated Unreal 4 features? Seems like they'd be showing those, considering they are promoting the Unreal 4 engine, rather than giving nVidia free advertising...
Oh. Honestly I assume this sololey because of how apex is integrated into UE3 and similiar those effects look.
If I'm wrong = great I will be happy.
But I'm 98% sure all of these things are build around APEX.
Replies
[ame="
http://www.wired.com/gamelife/2012/05/ff_unreal4/?pid=2564&fb_source=message&viewall=true
http://www.wired.com/gamelife/2012/05/ff_unreal4/?pid=2564&fb_source=message&viewall=true
Really hopping that "Real Time Global Illumination" is what were seeing in those shots. But either way i'm very happy to see emmissive as lighting as an option.
At this point I think its a given that there wont be baked lightmaps at the core of every level?
Yup:
This part was pretty interesting:
Hopefully this means its automatic and not just some pint light they attached to the hammer.
I hope cryengine lets us do this eventually. They got some interesting features in the cinema version of cry3 like area lights using LPVs, that would be cool too.
Actually now that i've think of it, seeing those scenes realtime in a game.. it would be pretty awesome,
and the quality only gets better in the future.
With them saying that there is a focus on improving the speed and efficiency of tools, I'm hoping some of that translates to them being inspired by Unity. UE3/UDK is no doubt very powerful, but its not the easiest engine to create new gameplay mechanics for.
[ame="
I remember being blown away by it back in the day. Unreal Engine is one of the best, if not the best engine..overall that is. It's not just the graphics that make it so powerful, but sadly it's the easiest part to talk about, especially for gamers.
So I think one needs to be careful when comparing it other engines. Especially the ones who actually have to work with it, the artist is only a part of the team, Epic probably have lots of sweet stuff for programmers/techies/animators/sound-designers/network-engineers/etc. But the consumer only understands how good an engine is based on how much raw graphical power it has, it's always been like that.
Sorry if I generalized too much, anyways I'd like to know more about:
And there's probably a lot more interesting questions than: how many particles can it render?
But nothing i'm sorry surpasses the epic demonstration of Valve showing off Half-Life 2 and Source engine. That was a mind blowing timeline to be marked.
[ame="
Are those normalmap seams? Will tangent space issues plague the next generation too?
Someone needs to go strangle Epic until they fix that.
I dunno. I'm sure the engine will be cutting edge. And I'm damn sure I don't understand most of the technology they are actually showing off. But it's hard to believe that this came from the same studio that made the samaritan demo, AFTER they made the samaritan demo, and not 15 years before (not talking in terms of tech, more, the style of the piece). My 2c.
What would be the purpose of this? Think the developers went all starry eyed over some bokeh and MSAA anti-aliasing when they saw the samaritan demo and stopped concentrating, so Epic pared it back a little for the next one? lol. I don't understand your point.
And also... demons in volcanoes? Seriously? That shit went out of fashion with Dungeon Keeper, seems like we're back in the 90's PC market days. :poly142: Wanna throw some particles around? Show me a storm chaser running around after hurricanes'n'shit man, some interesting story-telling ain't gonna hurt a tech demo, look at the Samaritan demo. That was tight. The demon in this demo looks like he should be on the cover art of a graphics card box. (No offence to any artists involved, just not personally feeling the design. Still scratching my head over how Epic could get it so so right with the Samaritan demo, then go with this)
But yeah. Looking forward to 'getting it' when I see the video come June!
Yeah I think this is probably the biggest focus of this, certainly reads like it from the article, unfortunately it goes right over my head :poly142: Not sure what's different about the previous lighting model; I guess running it from pure C++ makes it faster or more powerful I guess. Can anyone explain the differences in laymans terms? What makes this new way better?
^^^ EXACTLY!!!
Interesting. So no more 'Lighting needs to be rebuilt' warning?
I heard these exact words from somebody else who's played with it hands on.
not that I am at all trying to take away from UE4, i CANNOT WAIT to jump into ue4 when it arrives, every bone in my body wants to have a play with it.
You just answered your own question. How else are we expected to go 'I WAS SO WRONG THIS IS GONNA CHANGE EVERYTHING!' and then start frothing at the mouth?
But really I imagine it has something to do with the companies relationship with companies like SONY and MS, and making developers they want to court feel special by showing them these things way ahead of the rest of the plebs. :thumbup:
FYI, you can already do this in UDK if your workflow doesn't suck. You have archetypes, ini files and console commands at your disposal.
But I do agree, iteration time for programming in UE3 is horrific. Make a native code change and you can be waiting for 3-4 minutes (15 minutes on a lower-spec machine) before you can even test it - if there are no compilation errors to deal with.
story of my life.
I'm sure you could still do that. Performance is as major an issue as it has always been. I guess the point is that you have the capability to do it dynamically too now, if the scene/shot calls for it. But otherwise you'd probably still be better off baking it for performance reasons.
Any info that has come directly from epic (and not an article from a reporter that prolly doesn't have any technical knowledge?)
Hnnnnnnnng, I dunno, I need to see these in motion. Screenshot of anything simply haven't looked good this generation unless they were touched up afterwards or were taken in Prebaked Lighting: The Game, though those mountains and statues look very hot, love the materials and how good the lighting looks.
The other features sound pretty awesome though.. I haven't touched UE3 or UDK in ages, might just use this as a incentive to do things again.
And moreover, that latests rumors says that next-gen consoles will be on AMD GPUs (at least I hope so, I'm all against single company monopoly).
It seems like nVidia will keep on dominating the 'tools of trade' area of things, because lets face it, they did the smart thing, which was strikes deals and work WITH those companies.
They really should consider writing their own physics engine.
Or Crytek will take a lead. As all their tech is created in house. Except fmod and Scaleform.
Ever heard of Havok? Plugs right into Unreal.
It's just to deeply integrated within engine. I have feeling that Epic made very wrong decision here. Either for they or us (I hope it will be for them, as it's going to be lesser evil ;p).
Unless nvidia will finally stop using CUDA and port PhysX to DirectCompute.
Source? I don't remember reading that anywhere... how do you know those aren't dedicated Unreal 4 features? Seems like they'd be showing those, considering they are promoting the Unreal 4 engine, rather than giving nVidia free advertising...
If I'm wrong = great I will be happy.
But I'm 98% sure all of these things are build around APEX.