World Editor Video
Unfortunately recording the video with audio on the same machine caused various problems especially horrendous desynchronisation of video/audio and frame-rate issues. I spend half the afternoon trying to fix up the footage ending up cutting left and right and re-taking parts of it. This is why the video is cut together. Hopefully with the next videos I'm more lucky. So feel free to comment.
This video runs over a bunch of features of the editor giving an insight in how things are done and how the editor works. Due to ModDB still not giving any help on solving the video quality issue I've put up the video on YouTube, where it is more acceptable. I'm seriously disappointed how bad ModDB handled this video quality disaster so far (more like not handling it at all). Anyways here is the video.
Daily Grinding
In addition some more work on the engine front and the game scripts. Without going into details there had been bug fixing, improving editor handling and adding more features. I'll most probably show more the next time.
Outlook
The next editor videos should be less of a pain I hope since they should be not so long. Besides this there is more work to do on adding some more features for the first release. So look forward to some more videos next time.
![Drag[en]gine](https://media.moddb.com/cache/images/engines/1/1/9/crop_120x90/banner_large.png)
great video, I like your editor a lot.
Really great editor, the ability to customize pretty much anything and see how will it look in the game looks really handy. The only thing I'm missing is not seeing a preview of the object you are trying to place.
Does the engine support normal, displacement and specular maps? The city is looking great, but livening it up a bit with these techniques would go a far way to making it look comparable to modern games.
Also, seeing the Shield Liger in the city really changes one's perception of scale. I knew it was big, but not that big!
I've added a ticket for object preview while adding it.
The engine does support all advanced features like normal and more. You can read about physically based rendering here: Dragengine.rptd.ch . Furthermore some examples here: Rptd.ch . The scene here does contain all this. You most probably do not realize it since the materials are made to be natural. In other game engines the specularity is way overdriven and unnatural (specular/bloom in your face) so if you use a realistic shading this doesn't stick out to you as with others. If you don't realize that these techniques are used then the material is realistic. If you notice it then it's not realistic. This is valid for certian scenes.
What the scene is missing though is color variation like humidity stains, slight damages on walls, discoloring due to dirty water soaking in walls over time. Stuff like this I did not yet add.
Perhaps it's the combination of the subtlety of the effects in combination with the video compression that makes it so hard to see? I watched it in 720p fullscreen and it definitely helped, though it still seemed somewhat flat and unnatural. Perhaps can only really be seen when playing with the engine...
By the way, what about displacement mapping? (like in Http.developer.nvidia.com except less pronounced) It seems it would help with materials that have lots of height variation, especially at grazing angles, like Rptd.ch or Rptd.ch
Actually it's correct. The materials used in the scene like the pavement, the plaster walls, the concrete and metals do not have strong normal mapping. You can of course blow the normal map out of scale to overdrive the effect. In general though if you overdrive the effect in full bright situations you end up with horrible results in low light conditions. The beauty of physically based rendering is especially that materials work in all kinds of lighting situations. This also means that they look different in different lighting situations. So materials vary between flat and bumped look depending on the incident light direction and luminance contrast. It's best to not think too hard about material and lighting. Simply use realistic parameters and it all works out in time.
Concerning displacement mapping it is not yet implemented. I added a ticket for this.
Eh, I'm still not convinced the video compression isn't hiding the details. The realistic normal maps are very subtle, and even in 720p the compression artifacts are noticeable.
Sorry, I misunderstood you. Of course the compression in this video is rather large so you are right certain washout and loss of lighting is due to the compression.
Have you baked lighting for the map, or is this the preview light/shadow? There is something about the light. It seems to me like shadows are too bright and surfaces in shadows are too bright, too. And AO seems to work in corners, but not between objects. For example, between sidewalk and around buildings (on the ground), there seems to be no occlusion.
Lots of tools though and all seem to work as advertised. I like it!
There is no baked lighting involved. This is all real-time lighting all the way in the editor. The lightness of the shadows is based on realistic values. I've taken as an example a shot from my work place today: Dragengine.rptd.ch . The image right is in luminance and the values contain the sRGB luminance and the ratio in linear luminance. The ratio is 1:4 which is the contrast ratio on a bright sunny day between geometry in shadows and in light. In the engine I used 16 and 4 as sun light and ambient light intensity which is also a 1:4 ratio. So the luminance levels are realistic. What can throw you off though is tone mapping. This can alter the perception of these realistic values. Today there seems to be a bit of habit to use filmic S-curves for tone mapping. I personally don't like it since it blows up contrast and drives up the black level too much. In this one I'm using an enhanced reinhard operator which is more natural in theory. Tweaking the tone mapping though is the most tricky part. It influences the result a lot. I've not found yet the best curve yet especially with auto-exposure and the dragon character having a way different visual perception (better night sight).
Concerning AO it applies everywhere. Again other game engines tend to over-do AO in an attempt to make the effect jumping out at you. AO in real life is though more subtle. The current implementation favors more large scale AO. You can enabled also multi-scale AO which though costs more since you do AO 2 or 3 times averaging the result. In my tests it did not add that much more to the scene than single AO but you can enable this as player on your own if you like it. So while designing the game you should not expect a certain AO since players can pick their AO rendering the way they like it. It's more focusing on the content and letting the final choice of the rendering details up to the player to choose. You design the general look. The details the player can fine-adjust since everybody likes it slightly different.
How about Global Ilumination and reflections ?
It's not planned yet. I've not seen yet a GI solution which is not either impossible with dynamic geometry, crappy looking or horribly slow in anything but small test-scenes. I am looking into this topic from time to time but right now I've not come across something that's stable, fast and quality looking enough to warrant implementing it. If you think you know something that's working feel free to forward it to me and I'll have a look at it.
Yeah, there is no use implementing things which don't work yet, but will be no problem in the future.
A few things about lighting and AO you mentioned. 1)In real life, shadows are always fading out towards the edge and get darker towards the shadow origin. You can see, e.g. how a table leg throws a sharp and opaque shadow at its origin and then fades more and more with the remaining color. Soft Shadows are expensive, however it seems you have them in areas that are enclosed by shadow, but you don't have that towards the edge (of the shadow).
You are saying the values represent sRGB luminance, however your scene is rendered in Realtime (with Physical Based Lighting? I guess), which uses linear values, i.e. 32 bit images. So which image lights this scene and what bitdepth does it have?
Maybe this is too specific, so don't feel obliged to answer. I'm just wondering if some of the features could be made to look even better. I mean - no offense - it is a great looking engine with lots of tools and features, but the lighting is not yet convincing me. How would you go about adding a lightmapper though, if it is all in realtime? And why would you. My head is gonna explode and so will this comment. In 5...4...3..2...1..
Soft shadows indead are expensive. I'm not using soft shadows right now. If shadows look soft it's due to filtering on shadow mapping. So it can be called more side-effects or artifacts than soft shadows. I've experimented once with a penumbra approach but I did not re-enable that code. Would be interesting though to check out how it plays out with the stronger GPU I've got now.
I didn't express myself correctly there. The image I posted I shot from my window, converted it to luminance with GIMP and sampled the luminance values. The integer number is thus the sampled luminance in the range from 0-255 and thus sRGB. I then calculated the actual linear luminance belonging to that pixel to compare. This image itself is not connected otherwise with the engine. The engine itself renders (and lights) in 16-bit floating point linear color space and tone-maps down to sRGB space at the end. That's why I did the calculation on the shot image to compare directly with the engine.
Concerning lighting itself it sticks out the most in night time situations where the contrasts are very high. If you are in plain sun-light it's surfaces around you are bathed in the same light intensity so a scene in general. If you look at this image ( City-of-tomar.com ) you see how the ground looks flat due to the strong sun-light. Look at it at night with lights shining from different angles and the ground would become bumpy. It all comes down how you set up your lights, if it's day or night, sunny or cloudy, What goes for global illumination that's a different problem though. In this regard there is room for improvements.
About static light mapping it's not planed for the engine. Static light maps are quite restrictive and games become more and more dynamic. In general light mapping can be simulated by applying light map textures to components using the dynamic textures as shown in the video. But right now I'm not planing to mix dynamic and static lighting at the artist level. On the graphic module level it's possible to do so to adjust for weaker GPUs. That's something special the artist would not get in touch with.
I like this! I really like the dynamic lighting in e.g. Cryengine. I can work with simpler meshes than in Unreal Engine, where every mesh has to be closed/convex, as not to confuse the lightmapper.
I think the problem I see may be more with your current materials and textures than with the lighting itself. These very clean and straight textures just have a slightly artificial look to it. So, the lighting is probably great from what I've read here, just some assets that really show it off aren't there. Maybe I can supply you with the gun model I recently made (because it has a nice materiality+textures) and you could see how it renders in your editor. I just recently put it in U4 and it looks great and just like I wanted. The materials are definitely one thing I liked about UDK and like even better about U4. But your engine is just so cool and it is made by you, which I still find absolutely impressive!
That's correct. The textures I use are clean without any dirt. The reason is that I want to apply local variation using decals and other techniques later on. I didn't do this yet since I'm still trying to find good reference images (either on the net or shot by myself) to get the right level of dirtiness that would fit this area. Besides that I'm also improving on decals so I don't use them too much yet until I've finalized them enough. Some tickets are still around to improve them.
If you like I can give your gun model a try. I'll of course not give out the model or resulting images thereof unless approved by you so it would be a private demonstration unless you want to share some of the results. It's up to you.
In general I certainly am lacking good material to show what the engine can do. Some time ago I had plans for a demo scene but it somehow got lost in the wages of time. You happen to know test sets you think would be helpful?
Hes been working on this for many years, has to be more than 10 now, to compare this engine with cry engine or udk.
Is heresy, those are AAA engines, I would compare this to leadworks or phoenix engine, and whilst those are shiny, due to the higher quality of art assets used, they are miles behind this.
@dl whats the poly limits, i may have some old assets you can use.
I find this engine can compare to Unity and the workflow looks more hands on and practical than anything Crytek ever did. If I compare to Unreal 4 that's only because the engine is my daily bread. And U4 is simply amazing, yet still unfinished itself (e.g. Slate) . And there are hundreds of people working at Epic, while Dragonlord does it by himself. Imagine what 100 Dragonlords could create ^^
I also sent him some assets to see what the dirty materials would look like and how they compare. What would really make my day, is a modular material editor, such as Unreal uses or what I use in Maya. It's just so much more practical making shaders that way.
I don't think it's heresy. Just because something is not made by salary people doesn't mean it is bad or inferior.
Concerning poly limits there is none. If the graphic module thinks it's too heavy it can automatically adjust using various information obtained from scene definition. So yeah, just hit me with different polygon counts. If it's too much it's a good use case to adjust for.