View Single Post
Old June 21 2013, 12:08 AM   #6
Lee Enfield
Lee Enfield's Avatar
Location: Germany
Re: Virtual Tour : USS Enterprise (1701-D) Deck 1-4 (WIP)


Q: Maybe I missed it, but what's the final format of this going to be?
A: It's going to be a walkable area with access to the ship devices in realtime. We will (most likely) use the CryEngine3.

( Raytraced Image )

Test Render vs. Screenshot

I have to make a certain distinction on the visual quality of the pictures I present to you.

Most of the images I show to you are test renders(!) of the models I use for research or plan to use in a game engine later on. It means they are raytraced. So, what does that mean? It means a (potentially) higher rendering quality when it comes to light, shadows, materials,... all physical effects concerning light. It comes at a much higher rendering time cost. They still show the same models I want to use in the game engine, but since it takes some effort to bring the models in the game engine ( CryEngine3 - no integrated fbx-scene support, many restrictions on the properties of the models, only 16 bit data handling... ) I'll wait for it till the actual models have reached a state of completeness. It would mean too much unecessary work, to bring models of various stages in the game engine, without significant knowledge acquisition.
The test renders will vary in quality for time reasons.

Just when it comes to presenting you the lighting, the materials(textures), the FX, I will show screenshots(!) of the actual game engine. Those are things that have to be managed with the engine tools and present a different step in the development. To give a glimpse of what that could look like: there is a screenshot(CryEngine3) of models at the end of this post.

But to prevent potential confusion, I mark each image with a note, wether it is test render ( Raytraced Image ) or a screenshot from within the game engine ( Realtime Engine resp. CryEngine3 ). But for now and the coming posts you accompany me at various stages of the modelling process anyway. So it will be test renders, from here on.

Corridors - The Polygonial Force of Deck 2

Actually, Deck 2 has one of the lowest corridor counts of all decks. But since the other decks have a larger amount, I will not want to hold all the corridors objects at once in the rendering of the game engine anyway ( it would waste performance ) , I will concentrate on a partial approach.

The following pictures are part of my research. I made various version of the same model concerning the corridor for screen accuracy vs. resolution vs. polygon count reasons. So there is a continous development of the objects and expect them to change over time. Though, at one point, when I start on setting up materials/merge the parts asf in the engine, I'll consider the geometry of the object as more or less determined.

This is an assembly shot of various corridor models.

( Raytraced Image )

For instance, I am not satisfied with the yellow objects in this image.

( Raytraced Image )

Take a closer look. They aren't very screen accurate. And we would feel it in the end.

( Raytraced Image )

Here is an image of a newer type of this object. Better. But I think, I already got a better version floating around.

( Raytraced Image )

The next one is an example of a corridor assembly with placing markers on top of them.

( Raytraced Image )

In a lot of situations I want to know how much I can approach the limits of my set up or collect behaviorial data of the engine. It was the case here. So, I build a corridor out of it. It is important to understand that the polycount of the heaviest object in the scene doesn't go over 2000 polygons. But I deem it to much, if those objects get used on a greater scale. How they would perform in the game engine under a lot of stress would be declarative.

( Raytraced Image )

( Raytraced Image )

Research like this helps me to make certain performance gains by maintaining the same or better quality. It's time consuming, as well.

The next image shows an example geometry of the corridor framework. I treat it as a high-resoloution object (still under 2000 polygons), because having it on a greater scale in the scene would waste performance.

( Raytraced Image )

Thats's why I will most likely use LoDs here. What's a LoD ( Level of Detail )? Usually it describes a game asset that represents the actual game asset that gets loaded on a predefined distance, but with a lower polygon count. The problem with LoDs is, that they plop in the background, when they are loaded. So, making their visual appearance identical on their respective distances, to minimize this effect, is the key here.

The next one shows high-poly objects in the foreground, mid-poly further away and low-polys in the bakground. Mid an Low have a polycount of about half of their respective predecessor. The point of this picture is, that ther should be no visible difference.

( Raytraced Image )

And that's the promised screenshot done in the CryEngine3 with a lot of objects ( that currently are behind the corridor ), many(!) individual (cranked up, overlapping) light sources and other stuff. Performance was good, though no LoDs were used in this test scene.
Btw there are no texture coordinates, and just rough materials except for some objects. Everything still looks far away. But, then, it was a performance test.

( CryEngine 3 )

(P.S. There seems to be a problem with the image links of the first post. I'll correct that as soon a moderator sees my message)

Last edited by Lee Enfield; June 21 2013 at 12:38 AM.
Lee Enfield is offline   Reply With Quote