Real Time Arch Viz

[paulfox]

Hello, I'm new here but assuming this is the correct place to post this...

 

I'm currently studying for an MA in 3D Digital Design and am doing my thesis on the viability of game engines for real-time architectural visualisations (mostly going to be using UDK) and wondered what people's experiences of them are?

 

Do many people use them commercially and if so have you found that it helps clients/architects/property developers etc.?

 

Any help would be brilliant, thanks!

[Scott Schroeder]

The killer for real time arch viz in the early phases, for most places, is simply the deadlines imposed. It is near impossible to get a good quality real time presentation in the, "Oh we need this in 2 days" mentality. Then, you have the last 2 hours before its due changes that inevitably come along. All of that fights and clogs the pipeline that is needed to get good real time visuals. This isn't the jam my 5 billion poly SketchUp model in UDK and cross my fingers and hope it comes out good. To see how that screws things up, all you need to do is look at the Dallas Cowboys stadium that was done in UDK. Which has a playback of about 2 fps and the giant rows of exactly scaled and oriented trees.

 

However, once the bid and designs have been established you gain yourself a bit more time and real time becomes feasible.

 

You will have to contend with other factors. One being most architects/cleints think a real time engine like UDK is one of them bang-bang shooter games. They don't realize the power of serious gaming/simulation. All they think of it as is that COD thing them kids play. The other is cost. UDK isn't cheap. Yes, it is free. Yes you can create apps for free. However, once you start making money you have to pay royalties back to Epic. Usually in the terms of 25% after your first $500,000 made. Your pipeline also has to change slightly. You think to think in terms of, modularity, modeling optimizations, texture optimizations (ie no jpegs ever!), 2nd UVW lightmap channels, and proper unwraping.

 

Now if you are thinking that you'll just bake the light maps in max and be done with it, then why use UDK? Use Unity for that, since it is free and even Unity Pro isn't a very steep cost.

 

My 2 cents, either do real time right or stick to the traditional way of rendering. Nothing looks worse than real time done wrong, especially when games get it right and we don't. Real time could be a useful tool if given the proper development time. But that just won't happen over night.

 

Shameless self promotion time: http://docs.lib.purdue.edu/cgttheses/6/

My MS thesis on the very same subject.

[paulfox]

Hi Scott, thanks for the in-depth reply. I've actually already read your thesis paper as part of my initial research, it's very useful!

 

I'm still quite new to the whole real-time thing so on the surface it seemed like a perfect solution for letting clients, or even the public, explore unbuilt developments but then like you said there's all the set up time of things like only ever using targa files, baking lightmaps, static meshes limited to 65,000 vertices and people mistaking something created in a game engine for actually being a game etc. etc.

 

I think Epic could be onto something with making proper games available in web browsers, would make it more viable for arch-viz to use game engines as you could just email a link to someone and hey-presto they can theoretically explore the entire 'built' project.

 

I'm inclined to agree with you on the doing it right thing, it could be more of a hindrance if it makes any possible designs look crap. Maybe it could be used for massing studies, might help avoid some issues with quality and cost as you might not really be making any money off it, but then again using something like UDK for a massing study is probably a bit of overkill!

[Scott Schroeder]

It's good to hear that you've read the paper. I'm always curious to hear who has read it.

 

I don't think you will see Epic do too much on the web side. They have already stated that they won't port UDK to the web, they do mobile but not web. If you want an incredibly easy to use web player, you'll want to focus more on Unity. I also don't think Epic would be too keen on a company using their product on projects that are generating revenue and not be collecting some sort of payment. You aren't selling the real time app but you are using it on a project that will or could generate future income for your company.

 

One of the myriad of things you have to watch out for with this is that can people understand basic controls? How often do principal architects or senior architects use the WASD key layout for navigation? Can they really understand the project if they are stuck in a wall and don't know how to turn around? I know a few principal architects that struggle opening email so getting them to figure out WASD and mouse look or game controller controls would be like teaching a monkey to do brain surgery. There is some research into this topic if you have access to the SIGGRAPH white papers.

 

Another factor against real time is scale. With the old timey rendering, you render what you want the client to see and leave the backs of the buildings blank. With real time, you need to render all sides of the building. Every nook, every cranny. Which can get time consuming. Again, if you are going to restrict the view in real time, why do real time at all? Doesn't that defeat the purpose of being able to explore your project?

 

However, rendering is a snap with real time. With the project I did for last year's CGArchitect awards it was 45 minutes to bake my full lightmaps and after that, the render time to spit out high quality frames was as long as it took to play the animation. You can tell UDK to save each frame at full res, anti aliased, and capped at 30 FPS, then take those frames into post (After Effects, etc) and compile your super high quality video. It's the way most game cut scenes are pre-rendered in the engine. So if the animation was was 3 minutes, my render time was 3 minutes. If I wanted to add another camera for 1 more minute? That's just 1 minute of render time plus the time to add the camera. There is no need to re-bake light maps. So once you get your project into the engine, you gain massive amounts of time in rendering time saved. But does that time savings equal out the longer development time required to get the project into UDK?

 

Your example about a massing model is actually a good case study. It's a simple massing model so baking light maps would be a snap with automatic unwrap. If your client wants to see another view, you simply orbit the view in real time. There is no delay in rendering a new camera. But is it really worth it? How long would it take to create the same massing model in Max? What advantage, other than the unlimited views and the ability to move through the project, does real time offer in this type of project? Do you really need to make this type of massing project like you would an environment or could you just dump the entire max scene in UDK? It is simple massing after all. You could probably just create the masses out of BSP brushes in UDK even.

[corgnaac]

Hi,

I've been working with both engines Unity and UDK, i even tried to make the same arch visualization scene with each of them, and I have to agree with Scott, I think Unity is a more suitable choice for our area of work.

First on the GI solutions : UDK uses the lightmass system witch provide impressive results for a game lighting with high contrats and a kind of dramatic mood, but it's very difficult to set it up for architectural mood, especially for an interior. The settings provided in the UDK GUI are not deep enough to get the kind of even and smooth lighting you're looking for in arch viz interior lighting, so you have to go in the .ini files and find the good parameters to tune, veeeeeeery long. In Unity you get the Beast engine for free (with the pro version) witch allow you to have a very convincing result in a reasonable amount of time.

Concerning the controls, I couldn't say it better than Scott, that's critical. And to make that better suited for non-gamer, you will have to do some coding. Once again unity wins. Its open system allow to implement new functions or only modify the existing ones in a very simple maner, and once you have something you like, adding your code to other archviz solutions is as simple as a copy/paste, whereas in UDK you really need a strong understanding of the software's coding architecture just to get reed of the camera's tilt when the character walks...

That coding simplicity is decisive. I think the main advantage of a real time arch viz application, except the rendering time witch still doesn't provide a visual quality that can compete with a post-producted Vray rendered sequence, is the interactivity. As we use a game engine, why not propose functions that can provide a stronger experience to the viewer. With a well designed GUI you can go outside and see the neighbourhood (not considering the huge amount of work) for a real estate project for exemple, have some infos you couldn't make fit in a movie and so on. I think real time arch viz isn't opposing head-on with rendered arch viz, it's another product. The idea is that you can provide a lot more services than a video or a still, and that's when you'll be happy to have a simple and open dev system.

Last but not least Unity provide a web player wich still needs a plugin except with chrome for wich you can export a native application. For UDK, as a client, you need to download a 200 Mo at least file, and then follow an installation process as complex as any game's one. Not everyone can do that.

The only thing where Unity needs to get better (in our line of work, no questions about a AAA production, UDk is made for that) is about the shaders, its native library is quite short compared to the UDK's material editor, but once again it's quite easy to create your own shaders.

Just about to read your thesis Scott, looks very interesting.

[Scott Schroeder]

Xavier, I absolutely agree with you. The "cleanness" of architecture is why most real time GI solutions don't work so well without insanely high render settings or disabling the compression as you have to do in UDK. Games can hide the lightmass artifacts with grunge and grime or textures like brick and stone. Smooth or painted walls (even more if it's close to a white color) will show the lightmass artifacts like no other. Unity's lack of good stock shaders is a small hindrance, but thankfully there is the Strumpy shader editor which makes creating new shaders quite easy.

 

I think real time can get close to Vray (or other engine) as long as the proper time is given to develop your scene and there is a level of knowledge with the real time engine you are using. Which, that's where the bottleneck always happens in this industry. You really need to give the proper time in pre-planning and pre-production when dealing with real time. That stuff has to happen before actual work starts, it can't run concurrently or not happen at all.

[paulfox]

Thanks again for the brilliant information, guys.

 

It's looking like Unity might be the better way to go for the project rather than UDK. I think the project is still an interesting one to look at though and has some viability, as I'm sure you agree, Scott, after writing a thesis on it already!

 

With the state of current technology it does appear as it might be a more viable solution for smaller projects which can be created in greater detail rather than larger projects, the Cowboy's stadium again for instance. Although this would raise issues of whether a smaller project would provide the budget necessary to create a real-time walkthrough!

 

Scott, I like your point about easily being able to generate walkthroughs/animations. My previous project was a 1min 30sec Max animation which took about 90 hours of rendering, if it took maybe a day to transfer everything created in Max to something like UDK to render an animation in real-time that could potentially save a hell of a lot of time. But even with the fairly small scenes I created I still 'clipped' some things, for example I only textured one half of a rusty caravan because my animation path meant you only saw one half and eventually the landscape just ended but again this didn't matter because the animation wouldn't allow you to see it. My thinking with real-time is that you should be able to explore the full extent of a project but you will have to know when to cut it off. And adding to your point about the computer/game-literacy of a lot of people, how many architects/developers would 'die' walking off the edge of a map that didn't have any barriers? If creating enough extra scenery around your project takes an extra day then somebody's got to pay you for that day's work!

 

Xavier, I agree with your point that "real time arch viz isn't opposing head-on with rendered arch viz", in my initial thinking I wondered whether game-engines and the arch-viz-specific real-time engines might possibly replace the more traditional arch-viz but I see them as serving two different purposes; real-time would be more about exploring and evaluating a project whereas stills and animations are about marketing and showing off a project in all its glory.

[corgnaac]

That's right Scott the pre-production time should be planned in every real time project especially when you have to add some functionalities to enhance the visualization experience, and that's what is the most difficult to make the clients understand. Most of the time they expect a real time project to be cheaper and faster completed than a video... there is a lot of education and explaining to do on that level.

And yes mr Fox the real time offers a more pragmatic and "functional' approach to a project whereas the rendered pictures will show a dreamed result.

I have to say it's good to see people like you guys doing so deep and detailled research on that subject, things are moving.

[Scott Schroeder]

This was released for Unity a few days back, http://www.marmoset.co/skyshop

 

It might be interesting to see how this could be used to show models or even axon views. Though unfortunately, the don't offer a trail version so you'd have to buy it to try it.

[Bruce Hart]

On kind of a side note - one of the 3D guys in our office bought in an Oculus Rift headset the other day (he's always pushing the real-time thing). We all had a go at some of the demo scenes included with the pack, and a good percentage of the office got motion sickness - myself included. It had a Cool factor of 10/10 and perhaps a practical value of 2/10. Apart from the bad graphics, that was why VR headsets never really took off in the 90s

 

I think there will always be an advantage in providing the client with views of a building that WE want them to see rather than flying around aimlessly.

[Guest dialog]

It's good to hear that you've read the paper. I'm always curious to hear who has read it.

 

I don't think you will see Epic do too much on the web side. They have already stated that they won't port UDK to the web, they do mobile but not web. If you want an incredibly easy to use web player, you'll want to focus more on Unity. I also don't think Epic would be too keen on a company using their product on projects that are generating revenue and not be collecting some sort of payment. You aren't selling the real time app but you are using it on a project that will or could generate future income for your company.

 

One of the myriad of things you have to watch out for with this is that can people understand basic controls? How often do principal architects or senior architects use the WASD key layout for navigation? Can they really understand the project if they are stuck in a wall and don't know how to turn around? I know a few principal architects that struggle opening email so getting them to figure out WASD and mouse look or game controller controls would be like teaching a monkey to do brain surgery. There is some research into this topic if you have access to the SIGGRAPH white papers.

 

Another factor against real time is scale. With the old timey rendering, you render what you want the client to see and leave the backs of the buildings blank. With real time, you need to render all sides of the building. Every nook, every cranny. Which can get time consuming. Again, if you are going to restrict the view in real time, why do real time at all? Doesn't that defeat the purpose of being able to explore your project?

 

However, rendering is a snap with real time. With the project I did for last year's CGArchitect awards it was 45 minutes to bake my full lightmaps and after that, the render time to spit out high quality frames was as long as it took to play the animation. You can tell UDK to save each frame at full res, anti aliased, and capped at 30 FPS, then take those frames into post (After Effects, etc) and compile your super high quality video. It's the way most game cut scenes are pre-rendered in the engine. So if the animation was was 3 minutes, my render time was 3 minutes. If I wanted to add another camera for 1 more minute? That's just 1 minute of render time plus the time to add the camera. There is no need to re-bake light maps. So once you get your project into the engine, you gain massive amounts of time in rendering time saved. But does that time savings equal out the longer development time required to get the project into UDK?

 

Your example about a massing model is actually a good case study. It's a simple massing model so baking light maps would be a snap with automatic unwrap. If your client wants to see another view, you simply orbit the view in real time. There is no delay in rendering a new camera. But is it really worth it? How long would it take to create the same massing model in Max? What advantage, other than the unlimited views and the ability to move through the project, does real time offer in this type of project? Do you really need to make this type of massing project like you would an environment or could you just dump the entire max scene in UDK? It is simple massing after all. You could probably just create the masses out of BSP brushes in UDK even.

 

How would you get correct reflections in an animation with baked light maps?

[corgnaac]

Woaw, Scott, I didn't knew this plug-in, it look veeery good, I will have to test this. Thanks for the link !!

[helnash]

I have to admit the whole real-time thing for Arch Viz is something that hits a note with me, I feel that this has a big role to play in the future for this line of work especially with the abilities and what you can do within next-gen.

 

I also agree with that it takes some time to pre-plan awork flow for it, but being as you should always pre-plan your project it's not really that much extra time when you think about it. The real killer is the steep learning curve that HAS to happen if you chose to go down this road, I know this as I am on it at the moment.

 

Arch Vis has a very clean style of imagery especially for new developments and Game Art has that lived in feel of grunge, dirt and wear n' tear to it that helps you connect with the game, this I think is the big reason that Arch Viz doesn't seem to work that well in real time. A lot of people think they can just make the leap between the two disciplines, leaving textures looking flat, edges not flowing in the same direction or offset and overly obvious repeat tiling textures that when they catch the eye draw attention away from the purpose of the scene/level.

 

You have to take the time to learn UVmapping, and material definition with Diffuse, Specular, Gloss, Displacement (etc, etc) maps. Learning to unwrap your models properly and not just rely on the standard unwrap Box/Sphere/Plane etc, etc, will change the way you model (it has with mine anyway, and helped me understand modelling more and improved what I can do, not only in definition of the model but the time it takes me to build an object has reduced greatly) it takes me less time to unwrap an object to UV now as it does to build it in the first place (it took me hours if not days when I first started learning this technique but after a week or two I got the hang of the process).

At the moment I am concentrating on material generation (my portfolio work is taking longer because of it, but I am loving the results so far, and I'm only just getting started on it).

 

My husband uses Marmoset all the time, so I use it to test the materials I make before taking them into 3D Max, it really is a fantastic program, meaning I can make changes on the fly, even the smallest ones that make a huge difference to the rendered image without having to wait hours for a good quality render to see if something looks right (one thing while I remember, the normal bump will not show the same result in Marmoset as in 3D Max as you have to flip one of the RGB channels, hope that makes sense).

 

I am still rendering out the final images though at the moment as I have yet to fully commit to a real time engine, we have UDK (my son is learning it at the moment) but from what I understand it isn't really the right one for Arch Viz, I don't know much about Unity3D myself (but I bet my husband can give me a full run down of that one later).

The one that I am interested in is Cryengine 3 as everything I have heard is that this is the one for Arch Viz work, plus the results are just... wow...

 

 

This is a trailer for the engine showing Crysis3 so yeah all overgrown and destroyed environments but I can't wait to see what I can do with it when it comes to some clean Arch Viz work, might start playing around with it soon.

 

P.S @Scott I have downloaded your paper, and I will be having a read of that later

[Scott Schroeder]

How would you get correct reflections in an animation with baked light maps?

 

You can do it two ways. Either with a "fake" cube map reflection or a real time reflection. In, say, UDK you can put a sphere probe on your scene that generates a cube map of that area that you can use for your fake reflections. Or you can use a cube map from the interwebs. Real time reflections can make you take a huge hit on your FPS if you don't have the best hardware, so for general applications using a fake one is preferred.

 

Light maps are only for light and shadows, they do nothing for reflections.

[Scott Schroeder]

UDK, CryEngine, Unity, Twinmotion, Luminon, they are all suited for architecture. It just depends on how you use them and if you understand the program.

 

UDK and CryEngine are higher quality but come at a cost that 99% of architecture firms won't want to pay. Just because you can download them for free doesn't mean you can make money from them for free.

 

Some examples from around the web.

 

This one is from UDK:

 

This one is from CryEngine:

 

Annnnd back to UDK from the same artist that did the CryEngine one above

http://www.youtube.com/watch?v=l3heAKZYfpU

[beestee]

I don't think you will see Epic do too much on the web side. They have already stated that they won't port UDK to the web, they do mobile but not web.

 

This was pretty recent news, probably what the OP was referring to:

 

http://www.unrealengine.com/html5/

 

FWIW, it is UE running on the web browser, and little more than an experiment at this point but it does give indication that Epic is not ignoring the web.

[paulfox]

Through my research so far it does seem as though real-time would be at its most useful for development and simulation purposes and not for something like competing for jobs or maybe even marketing. It's interesting to note the amount of people that appear to be even looking into the field though even if it's not yet getting properly integrated into people's workflow. Hopefully it means the game engines will continue to develop new and better ways to be used by arch viz-ers and maybe even come out with feasible pricing structures!

 

Bruce, I've looked into the Occulus Rift as a further development point and it's pretty interesting. The low res nature of it is because the only version currently available is the development kit. I'm pretty sure they said the actual commercial release will be HD so I'd imagine at least 720p although I'm not too sure as I don't think a headset will be 16:9... Anyway, I'm not too sure of it's viability for arch-viz anytime soon but it does look pretty cool!

 

Also, I agree that it's helpful to provide clients with views you want them to see, this is partly why I think real-time could be useful as a development tool, something to be used at a time when your clients are firmly YOUR clients and you can show them all aspects of a project without needing to shield them from anything.

 

Hel, I completely agree that the learning curve is pretty immense. There's a hell of a lot to get your head around before you can even really start using it. It took me a little bit of time just to figure out how to get packages to load up properly after previously saving a level and exiting the editor! UDK does seem to be geared around grungey textures but I guess that reflects the lived-in nature of games. Those videos of Scott's are pretty awesome examples that it should be fine for arch-viz when you know what you're doing! That's a fair way off for me yet though!

 

Benjamin, that is what I was referring to, yes. I had a look around it, had to download the firefox nightly development version thing but it was impressive nonetheless. I think Chrome has a plugin that'll allow it to be played on the browser's current version but don't quote me on that. It's something that if it is developed further would help out a lot with an architectural workflow as you'd only need email a client a link (in theory!).

[paulfox]

On a slight side not, has anyone else heard of Euclideon and unlimited detail modelling?

 

https://www.youtube.com/watch?v=UO5tFZC8wWU

[Scott Schroeder]

I've heard of it as the brunt of many jokes, statements that it is just a rehash of current technology, or accusations of it being a hoax from the games folks. Show me unlimited detail on 1,000,000 unique objects and I'll be slightly more impressed.

 

Right now, it's just instancing which most game engines are really good at handling in the first place. Sure your elephant as 540,000 polys. But it's one copy instanced around, ditto with the rocks.

 

http://www.kotaku.com.au/2012/09/euclideons-given-up-on-unlimited-detail-for-games-its-new-website-suggests-so/

[Jonathan]

Ive spent some time on realtime development recently, my conclusion is that realtime and arch-viz must progress from the simple 'walkaround' notion adopted from game engine mentality to a hybrid form which allows for more control of content. Without a specific and more linear timeline interactive walkarounds can be quite dull and meaningless right? I would suggest a hybrid approach fusing 3D navigation with interactive video, imagery etc would be more appealable to clients and offer greater potential to 'sell' and frame stories.

Occulus Rift looks great for single users, not sure how this would translate to archviz though? And my shameless plug , ENTERactive - immersive and interactive dome experiences: http://pixogram.co.uk/?page_id=1439

[Jonathan]

Euclidean's real alright, I saw it demo'd last year. Interactivity with huge Lidar point clouds is a breeze, its not just instancing, http://www.euclideon.com/products/geoverse/ How they are going to transfer this tech to the rest of us though is still uncertain although I suspect we will all start to move from polygons to points in the future.

[Scott Schroeder]

Meh, if unlimited detail was so groundbreaking more than zero of the big game development companies would have backed it especially as the next gen consoles are coming online (Xbone's cloud computing would have been a good testing ground for this). But they all laughed and went on their way. That's why Euclidean has shifted away from games to more scientific viz.

 

All I've seen are demos, pre-recorded demos which could be fake or smoke and mirrors in any number of ways. I haven't seen any demo where someone is actually manipulating objects in real time. In the 2 years or so this has been out, there isn't much out there other than just words and pictures. Plus for a company that is supposedly on the cutting egde, they are always so hush-hush about their stuff. You can only get a demo if you request it for a small group? What is that, the magician who can only disappear if everyone else turns around?

 

I'm still highly skeptical about them and their "product." It doesn't mean it is a hoax, but I just can't figure out why it feels fishy. Maybe because for unlimited detail they use the same tree 6 bajillion times. Instances or not, if you want to convince me of your capabilities you might want to show more than one tree model.

[Jonathan]

Well, Ive seen it in real time in real life, it is real! But I agree something doesnt feel quite right, maybe thats down to dodgy PR though? Of course until they figure out how to integrate it with the current and wider industry unlimited detail will have 'limited use'.

[paulfox]

Admittedly I've only seen a few little bits here and there on Euclydeon and the Geoverse thing but it manages to look impressive and sound a bit dodgy all at the same time. I don't think it's helped by the fact they disappeared for a year or the comical voice overs! It is hard to imagine it being useful for arch-viz though as it's seemilngly all geared around displaying existing scanned data.

[hyperfocaldesign]

Another +1 for Marmoset Sky Shop, I've had a play around with that in Unity (free version). The real time shadows in Pro would be pretty awesome when combined with it. I imagine it will be the first of a number of HDR solutions. Its not the most accurate (it IS real time), but it sure does look nice, and you can tweak away endlessly with different values for exposure, diffuse, specular levels etc. They use a similar idea to sIBL where you have separate low res diffuse lighting maps, specular and a skybox/cube map.

 

I'll have to load in an architectural model and light it some time, have so far only messed with their default moped model with their sweet, sweet shaders attached.