194 réponses à ce sujet

[AngryFrozenWater]

The principle is the same though - just the engine has to do a lot more with the input parameters.

 

In X3 the parameters merely determine the colour and intensity of the star in the sector - the game engine works out how that's applied to the asteroids, spaceships, factories and everything in the sector uniformly.

 

An ME-type game could define very similar parameters but the engine would have to calculate far greater effects. Each "sun" object (at the most basic level) would have colour and intensity parameters. The planet/environment would have parameters that are affected by the sun - from lighting to weather patterns (based on energy input from the sun's intensity parameter, atmospheric composition and density, planetary rotational speed and the presence of any moons). The various Fauna objects would have a flag for being nocturnal ... and so on.

 

The actual calculations are far more complex but it still essentially boils down to having a bunch of objects with input parameters and you could completely change worlds by just tweaking those input parameters in each instance - that's pretty much how procedural generation works.

 

However, if the game attempted full dynamic atmospheric modelling, you'd need a Cray supercomputer to run it.

Nope. It is not comparable. Your view about how things are actually rendered on a planet's surface is flawed. Read my edited post above for an explanation.

 

Edit: Your view appears to be one of a modder or level designer. In which case your parameters and flags make sense. However, all that has to be rendered. That is calculated and drawn in real-time. Nothing happens automagically.

[FKA_Servo]

It's great for games like Skyrim and The Witcher but it's a dumb idea for a space game.

 

This cuts to the heart of it. Day/night cycles are fine in these games, and they would have been a good bet in DAI, although I agree with In Exile downthread that they're a little dumb when they go by so fast. If we're going to be visiting a wide variety of different planets with different astronomical circumstances, I don't see how a day night cycle makes any sense. But then, this is a Jazz thread.

 

I'm more concerned with ensuring that each of the hundred (?) or so planets that we're gonna be visiting is aesthetically distinct or interesting, which is a tall order already. This is why it's easy to look past this in DAI, incidentally - ignoring the fact that there were two too many desert zones, each zone was very distinct and beautiful, with its own unique character (and the non-dynamic, deliberately crafted weather in the zones looks as good or better than the dynamic weather in most games, including TW3, although I can't overstate how terrific TW3 looks overall).

[Chealec]

Nope. It is not comparable. Your view about how things are actually rendered on a planet's surface is flawed. Read my edited post for an explanation.

 

The edit doesn't actually change the underlying principle though - you would still set the global parameters then set the program running.

 

Say you have a solar system; one sun and a few planets (with moons). The parameters set would determine the initial state of the solar system when you install the game.

 

You can then enter orbit around a planet and the season, lunar phase, time of day and so on would be correct as determined by the state of the solar system at that moment in time.

 

Those same parameters would be used to help determine the atmospheric effects when you transition from orbit to planet-side but they'd be interacting with the planet rather than space. In terms of the game engine (unless you're attempting full atmospheric modelling) you're merely altering the primary light source and local environmental parameters which the engine has to deal with based on the current state of the solar system.

 

... and a day / night cycle on the planet is, at it's core, merely altering those input parameters over time.

 

 

You're not really doing anything massively different to what 3D engines have been doing since Quake.

[AngryFrozenWater]

The edit doesn't actually change the underlying principle though - you would still set the global parameters then set the program running.

 

Say you have a solar system; one sun and a few planets (with moons). The parameters set would determine the initial state of the solar system when you install the game.

 

You can then enter orbit around a planet and the season, lunar phase, time of day and so on would be correct as determined by the state of the solar system at that moment in time.

 

Those same parameters would be used to help determine the atmospheric effects when you transition from orbit to planet-side but they'd be interacting with the planet rather than space. In terms of the game engine (unless you're attempting full atmospheric modelling) you're merely altering the primary light source and local environmental parameters which the engine has to deal with based on the current state of the solar system.

 

... and a day / night cycle on the planet is, at it's core, merely altering those input parameters over time.

 

 

You're not really doing anything massively different to what 3D engines have been doing since Quake.

In that case I'm glad that MEA is not rendered using that magical Quake engine, because that one is BSP-tree based and can only be used indoors or for very small sections which give the illusion of being outdoors.

[Chealec]

...

 

Edit: Your view appears to be one of a modder or level designer. In which case your parameters and flags make sense. However, all that has to be rendered. That is calculated and drawn in real-time. Nothing happens automagically.

 

I was thinking more objects and parameters in code, as with C++ / OpenGL.

 

I never said anything happens "automagically" - it doesn't - the rendering engine just does what it's told. I was trying to work out what you'd need to tell it to do.

[AngryFrozenWater]

I was thinking more objects and parameters in code, as with C++ / OpenGL.

 

I never said anything happens "automagically" - it doesn't - the rendering engine just does what it's told. I was trying to work out what you'd need to tell it to do.

The "X3 Reality Engine" is using DX9, not OpenGL, for the Windows platform. You also used a game in your example which has completely different requirements (a planet rendering as seen from the surface of a planet versus one drawn from space). And you show no signs of understanding what the difference is. I'm no longer derailing this thread.

[Chealec]

The "X3 Reality Engine" is using DX9, not OpenGL, for the Windows platform. You also used a game in your example which has completely different requirements (a planet rendering as seen from the surface of a planet versus one drawn from space). And you show no signs of understanding what the difference is. I'm no longer derailing this thread.

 

OpenGL was an example - not specific to X3 but merely because I've never touched DirectX (and I've only passing knowledge of OpenGL) - so you're right, I probably am misunderstanding something fundamental. I understand that the requirements are different, the work the rendering engine has to do is different... but I write business applications rather than games - obviously the logic doesn't transfer well.

 

I was working under the presumably mistaken assumption that, under the hood, the presentation layer (rendering engine) would obey instructions from the application layer (game engine) and it would be the application layer that would determine the position and attributes of the light objects (et al) and leave it up to the rendering engine to put them on the screen and deal with the shadows, refraction and so on.

 

The application would say "make a green light, stick it here and move it along this arc" and the rendering engine would make it happen - so it wouldn't matter what was being rendered the underlying application logic would be the same... guess I was wrong. Sorry if I exasperated you with my ignorance.

[dreamgazer]

Yes, pretty graphics are pretty.

[Kabooooom]

What if instead of day/night cycles, they have day/night/twilight versions of maps and they randomly cycle each time you land on a planet or moon?

This would fix the problem of it being unrealistic that you witness a day/night cycle during a given mission (which shouldn't really take more than a day) while still maintaining the coolness quality of having day/night versions of environments.

I also support random "hazard" maps on planets as well.

[AngryFrozenWater]

OpenGL was an example - not specific to X3 but merely because I've never touched DirectX (and I've only passing knowledge of OpenGL) - so you're right, I probably am misunderstanding something fundamental. I understand that the requirements are different, the work the rendering engine has to do is different... but I write business applications rather than games - obviously the logic doesn't transfer well.

 

I was working under the presumably mistaken assumption that, under the hood, the presentation layer (rendering engine) would obey instructions from the application layer (game engine) and it would be the application layer that would determine the position and attributes of the light objects (et al) and leave it up to the rendering engine to put them on the screen and deal with the shadows, refraction and so on.

 

The application would say "make a green light, stick it here and move it along this arc" and the rendering engine would make it happen - so it wouldn't matter what was being rendered the underlying application logic would be the same... guess I was wrong. Sorry if I exasperated you with my ignorance.

Below you'll find a presentation of a lighting artist working with the Frostbite engine at DICE. During the development of the next Mirror's Edge game they had to adapt the engine and/or train of thought to the look and feel of that game, which contains mostly white colors, bright colors and glass. Even if the engine was already highly specialized in rendering realistic worlds, this still created some very specific problems for the engine or artists. Things like day and night cycles (which the engine was already capable of) needed to be improved, to make the sun, moon, buildings and glass as realistic as possible.

 

Lighting the City of Glass.

 

Now imagine fictional worlds with more than one sun, moon and/or binary planets and a day and night cycle. No doubt that creates problems I cannot anticipate. The average gamer may not care about the specifics of that, but it looks like EA's companies do care about those details. And that's great, because it gives these games a high wow-factor and drives technological advancements at the same time.

[Oldren Shepard]

Why is relevant for the story, i prefer they put that effort in the story or the side quests, character creation and body modification, wildlife and flora, gesture animation.

[nfi42]

Why is relevant for the story, i prefer they put that effort in the story or the side quests, character creation and body modification, wildlife and flora, gesture animation.

 

I don't think anyone want's if that's the cost of improving it.  I Don't,  I just think it would add to the game if it was there.

[AngryFrozenWater]

Why is relevant for the story, i prefer they put that effort in the story or the side quests, character creation and body modification, wildlife and flora, gesture animation.

Look at it this way: A game like MEA needs lighting artists anyway. Those people are highly specialized engineers. You wouldn't want them to create fish in a pond. They would be wasted there. Instead you want them to push the limits of their craft. I bet they would love that. So I say, go for it.

[Chealec]

...

 

Lighting the City of Glass.

 

..

 

That was an interesting watch - thanks. I wasn't entirely wrong about input parameters used to determine lighting and environmental effects - I was wrong about how/when they're applied and I was way off when considering the overhead from the amount of textures, the ambient occlusion, shadow effects, particle effects and so on that are required for dynamic lighting in a populated environment!

 

Not to mention all those little tweaks to make the in-game lighting technically "wrong" to make it look "right"...

 

I kinda figured a lot more of it was rendered on the fly on the GPU than is actually the case... don't think I fancy running a home cluster-farm and still getting a frame rate of about 1 frame an hour

[mopotter]

I do love Skyrim and the FO series which do this, looking at the sky at night and seeing 2 moons or lots of stars is pleasant.  I have a bard in Skyrim that plays her lute with the closest moon giving her light.  It's cool and yes, I do go pretty deep in those characters.   I also have a mod for camping equipment.  I don't travel at night, I try not to fight at night, I sleep or sit and wait till daytime when I can actually see what I'm doing.   

 

I wouldn't mind landing somewhere that has a planet rotation causing the night to last months instead of hours.  Anyone living there would have had to develop ways to grow things or have some other way of getting food, or maybe it's not developed but there is some reason to check it out.  

 

Or a planet where you can settle and it does have day and night.  But for the most part, if I'm going to be planet hopping I don't mind landing, doing the quest and leaving without watching the sun set and rise again. 

 

DAO had the camp and occasionally it would be attacked at night.  This would also work for me.  I

[Pasquale1234]

I haven't played a lot of games with day/night cycles, and even fewer where those cycles were meaningful.

Dragon's Dogma has them, and there are different enemy spawns at night (mostly undead, various ghosts) than during the day. You need to have a lamp (that consumes oil) to see much, and its illumination radius is rather small, so I guess it does create a somewhat spookier atmosphere.

Aside from that - you mostly get some mood / lighting changes, and have to wait for merchants to open / NPCs to show up.

BioWare does use atmospheric lighting in level design, and we've had some missions where we used flashlights to find our way. They also sort of emulated day/night in DA2, by allowing players to visit different parts of Kirkwall during the day or nighttime, where there were different conditions.

One characteristic of day/night cycles is that they tend to give one a sense of the passage of time. People sometimes complain about quests that are presented as urgent, even though nothing will happen until you arrive. I suspect that day/night cycles might make that urgency feel even sillier than it already does.

I'd like to land on different planets during full daylight, nighttime, different weather conditions, etc. - but don't really see much benefit in watching any of those conditions change during the course of my visit.

[Helios969]

What if instead of day/night cycles, they have day/night/twilight versions of maps and they randomly cycle each time you land on a planet or moon?

This would fix the problem of it being unrealistic that you witness a day/night cycle during a given mission (which shouldn't really take more than a day) while still maintaining the coolness quality of having day/night versions of environments.

I also support random "hazard" maps on planets as well.

That seems a reasonable compromise. I wouldn't mind that.

[vbibbi]

I actually wouldn't be bothered if there's no day/night cycle. I think those resources could be better implemented in other ways. I prefer there to be a range of atmospheres in different zones. I liked that Hissing Wastes and Fallow Mire were always night. Their ambiance would have been destroyed if we walked around them in sunny weather.

 

Weather effects would be better, and environmental hazards as dreamgazer says. Those would have more of a direct effect on the PC. The only thing night/day cycles really do is cause NPCs to shift location, and that can honestly be a pain to deal with. If we're going to have day/night cycles I wouldn't be opposed to DA2's toggle, so that we can choose the time. Better that than resting or waiting until dusk in order to move on to the next stage of a quest that requires stealth, etc.

 

The cycle doesn't accurately reflect time, anyway, since it's not a 1:1 correlation to the real world. So it can be a bit annoying walking across a large map to find out that 12 hours have passed and I now need to wait for another 12 hours. The game mechanics are already fairly divorce from real life mechanics, so I don't need this one element to be more realistic. It just emphasizes how unrealistic everything else is.

[malloc]

I die Everytime someone mentions toggle. It bothers me so much

[Snorka]

There is evidence to suggest the game might have a day night cycle found in the Mako conceptual prototype video. The palette of the demo is an Ice planet which starts with a sun above the mountain ranges, each cut of Mako gameplay the Ice planet environment darkens and eventually you see the Mako turn it's navagation light on. It's only a demo but if that is bought into the game that is just huge!