Thank you very much, Mik2121.
Please don't be alarmed about the instruction counts in the making of videos, 'cause they are not indicative of how it should be in any way. I didn't think people might spot them in those videos:D
if you check out this simple example I put together http://artisaverb.info/Desert/GM_Instructions.jpg
you'll see that the price for dumping the diffuse map is merely 14 instructions. And I believe that if someone far better then me puts this thing together we could make it fly.
Thanks LuCh! I appreciate the time you spent. Yeah, sorry about that canyon:) but at least I hope it got you wanting to know what comes next after it's finally over;)
zxcman, высокие пять товарищъ!:) Thank you very much, buddy.
Huge thanks, walreu. Gotta get one of those pointy hats one of these days.)
Nah...I kid, no wizardry here, but still thank you very much!
Thank you very much for your comment, SHEPEIRO. Very valid crit. This little bump was actually part of the whole huge sand crater mesh, so it was a bit cumbersome to work with, but still totally could've done more. My bad.
Hey, Vlad, it was never about beating anybody. I would totally love to read your making of, man. It's all about sharing and I'm sure you've got some great stuff to share! So you make sure to finish it up or I'll bug you about it forever.:)
Hey also got some sad news that youtube blocks the video in some countries so I thought I'd also upload it on Vimeo. If this was the case for you - feel free to grab it here: https://vimeo.com/43720484
Also some people were asking about my process for sculpting some of those details so I made this image:
I hope it might come in handy for some of you!:D
Also I'm still very curios to see if this technology could be applied in full scale production so all kind of input would be endlessly appreciated. Feel free to share!
You really inspired me with this project and method, I intend to start one of my own at a smaller scale of course, and see where I can get with it as a beginner.
I don't have time to read through all the comments above so i don't know if this was mentioned before but i was thinking about something.
The normal maps unlike the diffuse and specular can't be stored in 1 channel, the least amount of channels you need are 2. Now because the blue channel rarely stores significant information you can use the blue channel of the normal map to store in a gradient map, and you can just calculate the blue channel in UDK with the Derive Normal Z function. Where i want to get with this is that in one normal map you can store 2 gradient maps (in the blue and in the alpha) so basically using your method you can create a surface with just 1 texture. So for each normal map used you basically have 2 more gradients textures or detail textures or w/e.
Please correct me if what i said is wrong or if its taking away efficiency!
Thanks!
kinda curious how you managed to make all your sculpts tile such as the trim/motif patterns. I have tried something similar with the offset setting in zbrush but it doesnt seem to work with all the brushes, any tips on how to do this?
You really inspired me with this project and method, I intend to start one of my own at a smaller scale of course, and see where I can get with it as a beginner.
I don't have time to read through all the comments above so i don't know if this was mentioned before but i was thinking about something.
The normal maps unlike the diffuse and specular can't be stored in 1 channel, the least amount of channels you need are 2. Now because the blue channel rarely stores significant information you can use the blue channel of the normal map to store in a gradient map, and you can just calculate the blue channel in UDK with the Derive Normal Z function. Where i want to get with this is that in one normal map you can store 2 gradient maps (in the blue and in the alpha) so basically using your method you can create a surface with just 1 texture. So for each normal map used you basically have 2 more gradients textures or detail textures or w/e.
Please correct me if what i said is wrong or if its taking away efficiency!
Thanks!
You raise a very good point, although it should be noted that you cannot store an Alpha channel in a Normal Map that is compressed by UDK.
Apart from that though, you could theoretically create a single-texture complex material (unless I too am getting this wrong?).
I haven't watched the video yet but I can't wait to see it when I get home as this thread is inspiring
Seems to work, I imported it as TC_Default
Edit: if I import as any other compression type it gets screwed up, but it's still better than 2 different maps i guess? I have to check how this compression works and whats the actual difference between the types
I tried TC_normalmap Alpha and it gets screwed as well, don't know why, I figured that would be the one too.Maybe its some problem on my side.
Edit: the alpha works but the normal map gets all funny and contrasty
Sorry it took me forever to get back to you, but that's because I was preparing something really sweet for all you awesome boys and girls.
But first and foremost - your comments:
Tokusei, thank you very much, buddy!
I didn't use brush wrapping at all here. It's all made in 2.5d. I did my tools as shown here and then just placed them around the canvas. Like this.
Good luck with your stuff!
ae., huge thanks, man! I'm glad you like it)
Thanks, gsokol, much appreciated.
Hey there, Paunescu.Daniel, thank you, man.) I'll be interested to see how this will turn out. Also at the end of this post there's something that will make things more interesting for you:)
It's a pleasure to see your enthusiasm regarding the Normal maps. Reading comments was not really necessary there but I'm afraid you might have missed the paper I linked in the first post: http://artisaverb.info/DitchingDiffuse.html
If you're going to try a similar project on your own it might be useful for you.
Considering compression you are absolutely right, we should use the blue channel for gradient maps. Using the alpha channel would actually be a pretty big waste. Alpha channel occupies the same amount of memory as a full RGB texture, so it would be more efficient to have another gradient map/normal map combo instead of a single additional grayscale texture. At the moment UDKs Normal Maps co-compression is painfully visible which puts a damper on this idea for a while. It's strange 'cause UDN says that normal maps are also DXT, yet with the general texture compression co-copression is unnoticeable. I'll have to investigate it more sometime later.
Helder, bro, thank you very much! I appreciate the kind words.
So many things I still can't do so, hard to be proud but I promise to try at least for a day
Huge thanks, Iciban. Yeah I've seen some videos of Journey. I though it had an awesome art direction, so it's quite a flattering comparison. Thank again!:)
Hey there, HandSandwich, thanks a lot!
Thanks, Computron. Yeah I've seen those guys but it was a while ago and also inapplicable for real-time. But it seems like they've got some new stuff, so after I'm done writing this I'll be all over their website
Thank you very much, garriola83!
Thank you very much, Stephanie. Did you guys manage to visit Antelope Canyon during your time at Trion?)
SirCalalot, you're totally right. One texture material was the goal and it was achieved, though unfortunately with the use of alpha channel for now. Feel free to read up
on the paper. It has all the info on the subject.
Can't wait till you watch the video:)
Very sorry, SnowInChina. Yeah youtube and Sony Music are being a bitch on me. For that particular reason I also uploaded this on vimeo: https://vimeo.com/43720484
I added the link to the original post as well, so thank you for pointing my attention towards it. I hope you like the vid!
Wow, RogelioD, thank you so much. It means a lot to me when people enjoy this so much. Keep being inspired;)
And finally, there one thing I wanted to share with you guys...but I can't seem to remember what it is....
...oh yeah, [size=+4]THE MATERIALS![/size] Click the image to grab them!:)
There are all kinds of "procedural" materials for you to check out as well as a couple of example textures and meshes. Also there's a .PSD that makes for very smooth gradient map production as it allows you to preview your gradient mapping, normal, specular, damage and diffuse pattern influence right in photoshop! It's like you're painting your gradient map directly in UDK and can immediately see the end result! I've made a little video that will hopefully make things more visual for you:
I hope this will help you guys to do your stuff faster, prettier and more efficient! Though it does take a little getting used to, I can't wait so see what great stuff you awesome people will come up with. Arrrgh
Oh, and just in case, if there's something wrong or I forgot to plug something somewhere - report it here and I'll get it fixed.
Thanks for your detailed response, I read through your paper first time I saw it but didn't had time to go through the vids yet.
I was afraid that the Alpha channel is a bitch but wasn't sure, thanks for clearing things up.
I started some modeling on my environment, when things get serious i'l make a thread and link it.
Very impressive video, good explanations of the techniques too!
Purely an artistic crit, the main thing that stood out to me as needing work in the video was the camera motion, it was very much the "obvious long interpolated spline path" movement that sometimes plagues CG (especially game-engine based) videos.
I think with a few more cuts here and there, and with a bit more natural filmic "straight line" dolly paths and / or more wobble/bank here and there (especially more banking in the long canyon fly-through) the camera motion would have felt much more natural and less artificial.
That said, the whole video is a great achievement and far more complete than what most people manage by themselves.
The procedural approach is very interesting too, it's a great path to investigate down.
Paunescu.Daniel, no problems, man. Best of luck with your project!
Hey, Paul, thank you very much! I'm also glad you find the tech interesting. I hope it has some production future.
Regarding the camera work - very valid crit, man. Thank you very much! Now that you pointed that out it seems really obvious. I'll make sure to keep that in mind for the future!
This looks amazing! I'm completely blown away by the sheer amount of information you compiled and decided to share with us. Thanks so much for providing so much coherent info on how you approached this. I've never really grasped procedural workflows and instanced materials in UDK and this makes me really want to try it out.
Pretty cool ideas. Thanks for sharing this! Scrolled through the thread, looking forward to watching the videos.
My first thought was... this sounds like it requires a large number of shader instructions to pull off, which means it's going to hurt performance in a real game level with everything else going on (AI, physics, lighting, etc.). Generally this is why studios use simpler shaders with more textures. But that's just my first impression, I haven't digested everything in here yet.
Well, I finally got round to watching the original video and it actually blew me away!
Your direction is fantastic and this is an impressive project even if your were using Diffuse maps!
Hey, Eric, thanks for your comment! Well if we can trust how UDK calculates custom nodes instructions it costs 14 to replace a diffuse map with a gradient map. The image I linked on page 2 shows some examples:
(damnit with all those pages stuff gets lost )
Adding a diffuse pattern on top is just 2 more instructions. Of course damage blending and sand or snow or whatever cost extra but so far I believe it is comparable with analogous approaches instructions-wise. But you don't have to use all of that functionality. The basic shader is 73 instructions and it covers spec, normal and diffuse with 1 texture. The biggest problem here so far is that because of texture co-compression in UDK you can't put a gradient map into the blue channel of a normal map to have your material described by a single RGB texture. You have to go with RGBA and that is not very economic. But there has to be a way to solve this, I'm just curios to find someone who knows how.
SirCalalot, thank you very much once again. That was the plan and I hope it worked out.
Watched the videos. An impressive amount of work! I especially loved the room at the end, pretty pool, reminded me a bit of the latest Castlevania. Also loved the antelope canyon, must have been fun to play with the lighting. Good job!
Looks like the final instruction count is around 230 or so? Shader complexity is a real barrier these days. It's not just 14 instructions, it's adding this again and again for all those controls. If you're controlling color, normal map, and specular, all with these gradient/height maps, then that can get really expensive. Works great for a portfolio piece that can be rendered out to a video, but usually doesn't work so well for a real-time game that someone is playing.
It's really an unfortunate wall. As an artist I want all these controls and surface details, but I have to dial it back to allow the game to perform well.
Building a complex shader is great as a learning experience. Really helps you understand how far you can push a technique. And you've pushed this one pretty far, looks good! I'm curious how far you could optimize this.
This is a great portfolio piece, don't get me wrong. The optimization part goes above and beyond what most employers are looking for in their candidates. I want to be clear I'm not disparaging your work. It's a beautiful result, and lovely of you to share the workflow so thoroughly! I just want to clarify why this process is not used more often. When it's used, it's used sparingly, because the fill rate cost can get very high very quickly.
About normal map compression. Yeah, just a fact of life I think. So you could either use a single uncompressed file and pack it all into one... R and G for the normal map, B and A for two height maps (is that right?) Or you could use two textures and compress them both... DXT5nm normal map (just red and green stored), plus a DXT1 map with three height maps in it.
Though I'm afraid I've confused you with the shaders. I've got to make a note on that "making of" video or something:)
When I say 73 instructions I mean 73 instructions for a perfectly, fully functional ready-for-use shader and that is with only 1 texture sampled(!), so it is already a pretty nice optimization:
[ame="http://www.youtube.com/watch?v=a4TcnfX5c3Y"]Procedural Materials Tutorial & Giveaway - YouTube[/ame]
[size=-1](I'm sorry to repost the video, I just wanted to link it, since it describes all the materials, but it just embeds all by itself)[/size]
Adding overlayed diffuse component on top is only 2 instructions more.
230 was just an unoptimized version of the shader with both kinds of damage generation and vertex blended sand. Right now this shader performs at 156 instructions, feel free to download it, give it a spin and all the other shaders as well.
All of them are less then Epic used for their vertex painted wet/moss surfaces from foliage map demo. But you definitely don't have to or even shouldn't use the most expensive one's all the time.
Gradient map is used only once to create the diffuse component and then specular, as it usually is, is just a contrasted colored version of the diffuse. So there is no adding it again and again - it's just one single time.
So in all honesty I still believe that this approach has dramatic potential for replacing a big share of our diffuse maps. So far I haven't seen a solid argument against it performing it's purpose less efficient than RGB diffuse map approach. In fact the optimization capabilities surprised even me and pushed to find new ways to comfortably cram more content into gradient maps(hence the PSD file in the video).
And that is with only half-witted me working on it.
So far, if middleware architects like Epic give this a proper integration I'm pretty certain that it could kick diffuse maps ass so hard for too many purposes. I mean, there is a whole environment built using only gradient maps and yet no one could(or would want to - which is even more important) tell the difference.
Considering the NM co compression I also thought I'd clarify 'cause I'm afraid someone might take double "co" as a type-o Cocompression means that you RGB channels upon compression get there values mixed up together:
So when you try to stick your Gradient Map into the mostly useless blue channel of your Normal Map you get this:
You could try to use default texture compression but that would take a lot of kick out of your normal maps, which is also bad, when you rely on it so much:
Though it could be the way to go since most of the console games are really short on RAM.
So yeah it is the fact of life, but it doesn't mean it doesn't have to be changed.
In an industry that is all about efficiency blue channel of the Normal Map is a downright waste of 1/3 of our Normal Memory budget. Now how can we talk about new technology and more memory when we sit there doing nothing about this black hole sucking on our resources? I know that texture compression is a touchy subject and I perfectly realize that it is hard, but it doesn't mean that It should avoided. It means that the awesome programmers should strap on a pair and give it hell. There's nothing that can't be done I just hope there'll be enough incentive for it.
Or it could be just a UDK issue and you could actually get this sorted out by your good old graphics programming friend - I don't know:)
All I know is that I would love to see artists define whole surfaces with single RGB maps, saving so much money and memory and having time to make their games awesome where they have to be.
Is co-compression your own term, or did you find it somewhere else? AFAIK there's nothing special about what Epic's doing with their compression, it's plain vanilla DXT. Here's some info. http://udn.epicgames.com/Three/NormalMapFormats.html
If you want to store four channels of data, two of them for a normal map, then TC_NormalmapAlpha is probably the way to go. Though it will probably give you a block-artifacted normal map though, just because of the way DXT compression works.
There's really no way to avoid this, unfortunately. If we want to use compression, it's going to be lossy.
Yeah it seems like it should to be plain vanilla DXT but it doesn't behave that way. The very article from UDN you linked says that Normal Maps are compressed into DXT1 But that is what default compression should be aswell, since it is the most economic and widely used type of compression. Yet the TC_Default compression doesn't produce such severe co-compression artifacts as TC_Normalmap does. That's really weird. Yet if they can do it with no co-compression for all their textures but normal maps, I'm sure they can do it for normal maps aswell. Provided enough incentive.
If we would have a single 3 channel texture for Normal Map + Gradient Map with proper compression it should become a no-brainer to replace a lot of diffuse maps with my "procedural" approach in a lot of places. There might even be a workaround this right now, like using Default compression but adjusting your normals previously to compensate for lost contrast. I just hope to get my hands on some awesome graphics programmers sometime soon to get to the bottom of this
I don't know what exactly TC_Default is doing. But they do advise simply using TC_NormalmapUncompressed with half the resolution (i.e. 512x512 instead of 1024x1024), which results in the same memory cost as a 1024 DXT1, but with no compression artifacts.
I don't know to for sure too, Eric will have to find out.
The trouble with uncompressed is that it stores only two channels, disregarding much needed third one, so unfortunately it's not an option.
Thank you very much, OBlastradiusO. Yeah I get almost all my highpolies from zbrush. Though when baking heightmaps from complex 2.5d compositions sometimes you might end up with something like this:
Which is not really useful. So in that case I create a heightmap from the normal map in crazybump. It's really neat because instead of global height relations you get local ones, that carry much more relevant diffuse information.
The trouble with uncompressed is that it stores only two channels, disregarding much needed third one, so unfortunately it's not an option.
Oops, yeah. I'd be surprised if they didn't have a plain vanilla ARGB uncompressed format somewhere. It'll be about 3x the size of DXT5, but might be worth it if you don't want the compression artifacts.
Awesome work dude. I hope that we start seeing better tools to help artists do this kind of thing so you don't need to be half a programmer to get good art with low texture usage.
The problems you're getting with TC_NormalMap aren't because of co-compression, it's because TC_NormalMap isn't a compression setting but a pipeline setting. TC_NormalMap gets automatically interpreted differently in the shader, and the engine performs a preprocessing step on it before compressing them to accentuate the normals. It does this so you lose less information on compression, but because the normals are accentuated and then renormalised, information from the red and green channels bleeds over to the blue channel.
I don't know to for sure too, Eric will have to find out.
The trouble with uncompressed is that it stores only two channels, disregarding much needed third one, so unfortunately it's not an option.
Thank you very much, OBlastradiusO. Yeah I get almost all my highpolies from zbrush. Though when baking heightmaps from complex 2.5d compositions sometimes you might end up with something like this:
Which is not really useful. So in that case I create a heightmap from the normal map in crazybump. It's really neat because instead of global height relations you get local ones, that carry much more relevant diffuse information.
Kurt Russell Fan Club, thanks a lot, buddy.
Yeah, that would explain a lot of things. I tried to tinkle in photoshop and udk to try to mimic the effect of TC_Normalmap but so far to no avail. I'm shamelessly trying to bug someone who might be able to know more about this stuff. We'll see how this goes, but if we'll figure this out I'll be more than glad to update giveaway materials:)
Thanks for the idea, Eric, though it could be a different issue altogether. I'll try to investigate and see where this leads us.
Hey, Eric Well if we can trust how UDK calculates custom nodes instructions it costs 14 to replace a diffuse map with a gradient map.
It has been my experience to not trust Unreal when calculating the cost of your custom node. Primarily because the material editor does a number of optimization under the hood when you are making a material(I believe that it's called folding). However this is completely bi-passed when you use the custom HLSL input. A great work around to this is using Performance HUD or PIX to profile your shader and see what the actually cost of it is.
just to chime in on this as well: it's a totally interesting idea, but every time you expose all those variables and tweak them externally, you are just moving memory cost to the shader databases. you might save some texture memory but it'll be eaten up somewhere else, and then on top of that you have a massively expensive series of shaders to render on everything.
i don't think it's effecient at all.
Surely pulling info from object normals, vertex colours, world-space positions etc would give you a similar kind of "unique" detail and not impact rendering performance and shader memory as much.
check out some work by bram eulaers or philip k and see the lengths you can go to with a good tiling texture setup using tradition dif nrm and spec/gloss maps. throw on some "procedural" world position/object normal/vertex colour tweaks and you could take it really far, without sacrificing memory in all these other places.
also, unreal is a very unique engine in how it handles certain things. they take a massive overhead cost for their instanced meshes, so it makes sense to take advantage of that as much as possible to actually get somethign back from initially taking that cost. but many engines don't have that kind of feature, so your memory can be spent in many other areas. with good texture streaming, clever optimisation of textures and assets, textures are very rarely a problem in current gen games unless you're building something really left-field like an open world game where you can fly around at 100mph and load 50 square kilometers in a minute.
the biggest problem you'll have is mesh memory, poor LODs and expensive skinned meshes will chow down much more memory and cause many more problems than a few textures loading in a lower mipmap.
just saying, it seems like solving a problem that didn't really need to be solved as far as memory is concerned.
as far as saving time/money in production, would that technique really be viable to a realistic game where phototexturing is a requirement? the amount of mask textures you'd need to get a good amount of material definition, along with the shader cost of setting it all up seems like it'd just push time cost into memory cost, and you'd end up with a game that looked very "samey", took a year to make and had poor frame rate.
i think it'd be far better to have a collection of good tiling textures that are used widely, and use RGB, full colour, masks along with other techniques, to add in variation and detail. or just accept that we're stuck with 90mb +/- of texture memory and be clever about how we build things, keep shaders cheap and effecient, and get some good variation in surfaces. spend memory on lighting and post effects rather, as that'll give you more bang for your buck - shitty textures can be saved by good lighting but not the other way around, for example.
anyway, just playing a little devils advocate, i like what you did and there's some great stuff to think about but i don't believe it's worth throwing away everythign and embracing something like this without thinking about just what we'd get from it and what it'd cost us.
Hey, |*BILLY$CLINT*|, yeah I also read somewhere that UDK shouldn't be trusted much on that one, but I don't know how to check it out. Would be so kind to elaborate on those ways you mentioned? much appreciated.
Hey, Rick_D, I have no trouble with you being the devils advocate:) in fact it's fun to defend your ideas. So here goes:
...every time you expose all those variables and tweak them externally, you are just moving memory cost to the shader databases...
I'm sorry I don't quite follow. Are you suggesting that having another material instance is more memory intense then having another texture?
a good tiling texture setup using tradition dif nrm and spec/gloss maps. throw on some "procedural" world position/object normal/vertex colour tweaks and you could take it really far, without sacrificing memory in all these other places.
other places?
...textures are very rarely a problem in current gen games...
the biggest problem you'll have is mesh memory, poor LODs and expensive skinned meshes will chow down much more memory and cause many more problems than a few textures loading in a lower mipmap.
as far as saving time/money in production, would that technique really be viable to a realistic game where phototexturing is a requirement? the amount of mask textures you'd need to get a good amount of material definition, along with the shader cost of setting it all up seems like it'd just push time cost into memory cost, and you'd end up with a game that looked very "samey", took a year to make and had poor frame rate.
I still don't understand what "other" textures you're talking about. There's a single normal+gradient combo and a single combined texture from grayscale masks. And don't forget that you use your masks for multiple materials.
Also it took me 4 months(and yes a lot of the time saved is due to this tech) to produce the whole environment you see on the first page from the ground up including conception and I haven't seen a single person consider it "samey", in fact, until told none of the professional artists who's seen it prior to release had any idea there might something "unusual" with diffuse maps. If the artists see no difference then the audience won't for sure. It's also about choosing your battles, getting anal about every texture when you've got a whole location to make and your audience won't know the difference is at the very least a waste. I'm against "making things for games" mentality. Make games and put your effort where it matters.
But of course you've got to use this tech smartly and it has it's limits.
spend memory on lighting and post effects rather, as that'll give you more bang for your buck - shitty textures can be saved by good lighting but not the other way around, for example.
that's exactly my point. do textures fast, cheap and almost identical visually.
i don't believe it's worth throwing away everythign and embracing something like this without thinking about just what we'd get from it and what it'd cost us.
No one said we should. In fact the purpose of this particular thread is to by all means encourage people to propose valid counter arguments to why this isn't feasible. I'm the first one who would like to know.
So far after 12000 views, NVidia engineers reposting it on their blogs and me shamelessly mailing people about it like crazy I'm yet to find one kind soul who can explain why this approach has no merit.
Rated A for AWESOME
Hi all i'm from Italy it's 2 long years me and a friend are up to make a game and allways stoped the work cuz : -Blender to UDK = S****T (but I dont have 5000$ for 3DsMAX) , Gimp to texture = OMG (PS costs 2 much for me ) , and UDK to materials and stuff = NO GOOD TUTORIAL (only things usefull to make games that seems 5 years old graphics ) , all the people keep the fancy stuff like pure GOLD no one shares ... -.- ' So I registrated here cuz this post is AWESOME 10+ , this guy is a GOD and in 2 years is the first time someone shares a good stuff , so from me u get 10000000000000000 kisses and thanks .
P.S. sorry if I have a bad english .-.
There is a problem when i fully load the package it gives me this error :
[
MISSING FILES :
Can't find file for package 'd1v_ND_Test' while loading ..\..\UDKGame\Content\ProcMat_Demo\d1v_ProcMat_Demo.upk
Can't find file for package 'd1v_ND_Test' while loading NULL
MISSING OBJECT :
d1v_ND_Test.Materials.Base.DetailMap (Check the log to see all references!)
]
I downloaded the .rar extract it in to its own folder then I put the whole folder under udk/UDKGame/Content , even tried to put only the .upk does the same thing and to give it a try i put your mesh in editor and tried to paint just to see how it works Red=more color/contrast+cracks(btw i tried the diferent MAT but the cracks are allways visible cant get them off even tried combos like red+blue and so on ...) , Green=brown stuff , Blue=NONE ?(nothing changes) and Alpha=Sand .
So the question is , is this thing normal ?
Replies
Please don't be alarmed about the instruction counts in the making of videos, 'cause they are not indicative of how it should be in any way. I didn't think people might spot them in those videos:D
if you check out this simple example I put together
http://artisaverb.info/Desert/GM_Instructions.jpg
you'll see that the price for dumping the diffuse map is merely 14 instructions. And I believe that if someone far better then me puts this thing together we could make it fly.
Thanks LuCh! I appreciate the time you spent. Yeah, sorry about that canyon:) but at least I hope it got you wanting to know what comes next after it's finally over;)
zxcman, высокие пять товарищъ!:) Thank you very much, buddy.
Huge thanks, walreu. Gotta get one of those pointy hats one of these days.)
Nah...I kid, no wizardry here, but still thank you very much!
Thank you very much for your comment, SHEPEIRO. Very valid crit. This little bump was actually part of the whole huge sand crater mesh, so it was a bit cumbersome to work with, but still totally could've done more. My bad.
Hey, Vlad, it was never about beating anybody. I would totally love to read your making of, man. It's all about sharing and I'm sure you've got some great stuff to share! So you make sure to finish it up or I'll bug you about it forever.:)
Hey also got some sad news that youtube blocks the video in some countries so I thought I'd also upload it on Vimeo. If this was the case for you - feel free to grab it here:
https://vimeo.com/43720484
Also some people were asking about my process for sculpting some of those details so I made this image:
I hope it might come in handy for some of you!:D
Also I'm still very curios to see if this technology could be applied in full scale production so all kind of input would be endlessly appreciated. Feel free to share!
I don't have time to read through all the comments above so i don't know if this was mentioned before but i was thinking about something.
The normal maps unlike the diffuse and specular can't be stored in 1 channel, the least amount of channels you need are 2. Now because the blue channel rarely stores significant information you can use the blue channel of the normal map to store in a gradient map, and you can just calculate the blue channel in UDK with the Derive Normal Z function. Where i want to get with this is that in one normal map you can store 2 gradient maps (in the blue and in the alpha) so basically using your method you can create a surface with just 1 texture. So for each normal map used you basically have 2 more gradients textures or detail textures or w/e.
Please correct me if what i said is wrong or if its taking away efficiency!
Thanks!
This really reminds me or the game Journey
Really great stuff all round! Mad props to you!
once again sick work ^^
Apart from that though, you could theoretically create a single-texture complex material (unless I too am getting this wrong?).
I haven't watched the video yet but I can't wait to see it when I get home as this thread is inspiring
Edit: if I import as any other compression type it gets screwed up, but it's still better than 2 different maps i guess? I have to check how this compression works and whats the actual difference between the types
*sad face*
Actually you can, you just need to use a different compression format which is TC_NormalMap by default to TC_NormalMapAlpha
Edit: the alpha works but the normal map gets all funny and contrasty
Sorry it took me forever to get back to you, but that's because I was preparing something really sweet for all you awesome boys and girls.
But first and foremost - your comments:
Tokusei, thank you very much, buddy!
I didn't use brush wrapping at all here. It's all made in 2.5d. I did my tools as shown here and then just placed them around the canvas. Like this.
Good luck with your stuff!
ae., huge thanks, man! I'm glad you like it)
Thanks, gsokol, much appreciated.
Hey there, Paunescu.Daniel, thank you, man.) I'll be interested to see how this will turn out. Also at the end of this post there's something that will make things more interesting for you:)
It's a pleasure to see your enthusiasm regarding the Normal maps. Reading comments was not really necessary there but I'm afraid you might have missed the paper I linked in the first post:
http://artisaverb.info/DitchingDiffuse.html
If you're going to try a similar project on your own it might be useful for you.
Considering compression you are absolutely right, we should use the blue channel for gradient maps. Using the alpha channel would actually be a pretty big waste. Alpha channel occupies the same amount of memory as a full RGB texture, so it would be more efficient to have another gradient map/normal map combo instead of a single additional grayscale texture. At the moment UDKs Normal Maps co-compression is painfully visible which puts a damper on this idea for a while. It's strange 'cause UDN says that normal maps are also DXT, yet with the general texture compression co-copression is unnoticeable. I'll have to investigate it more sometime later.
Helder, bro, thank you very much! I appreciate the kind words.
So many things I still can't do so, hard to be proud but I promise to try at least for a day
Huge thanks, Iciban. Yeah I've seen some videos of Journey. I though it had an awesome art direction, so it's quite a flattering comparison. Thank again!:)
Hey there, HandSandwich, thanks a lot!
Thanks, Computron. Yeah I've seen those guys but it was a while ago and also inapplicable for real-time. But it seems like they've got some new stuff, so after I'm done writing this I'll be all over their website
Thank you very much, garriola83!
Thank you very much, Stephanie. Did you guys manage to visit Antelope Canyon during your time at Trion?)
SirCalalot, you're totally right. One texture material was the goal and it was achieved, though unfortunately with the use of alpha channel for now. Feel free to read up
on the paper. It has all the info on the subject.
Can't wait till you watch the video:)
Very sorry, SnowInChina. Yeah youtube and Sony Music are being a bitch on me. For that particular reason I also uploaded this on vimeo:
https://vimeo.com/43720484
I added the link to the original post as well, so thank you for pointing my attention towards it. I hope you like the vid!
Wow, RogelioD, thank you so much. It means a lot to me when people enjoy this so much. Keep being inspired;)
And finally, there one thing I wanted to share with you guys...but I can't seem to remember what it is....
...oh yeah, [size=+4]THE MATERIALS![/size]
Click the image to grab them!:)
There are all kinds of "procedural" materials for you to check out as well as a couple of example textures and meshes. Also there's a .PSD that makes for very smooth gradient map production as it allows you to preview your gradient mapping, normal, specular, damage and diffuse pattern influence right in photoshop! It's like you're painting your gradient map directly in UDK and can immediately see the end result! I've made a little video that will hopefully make things more visual for you:
[ame="
I hope this will help you guys to do your stuff faster, prettier and more efficient! Though it does take a little getting used to, I can't wait so see what great stuff you awesome people will come up with. Arrrgh
Oh, and just in case, if there's something wrong or I forgot to plug something somewhere - report it here and I'll get it fixed.
Have fun!
I was afraid that the Alpha channel is a bitch but wasn't sure, thanks for clearing things up.
I started some modeling on my environment, when things get serious i'l make a thread and link it.
Purely an artistic crit, the main thing that stood out to me as needing work in the video was the camera motion, it was very much the "obvious long interpolated spline path" movement that sometimes plagues CG (especially game-engine based) videos.
I think with a few more cuts here and there, and with a bit more natural filmic "straight line" dolly paths and / or more wobble/bank here and there (especially more banking in the long canyon fly-through) the camera motion would have felt much more natural and less artificial.
That said, the whole video is a great achievement and far more complete than what most people manage by themselves.
The procedural approach is very interesting too, it's a great path to investigate down.
Keep up the good work, and thanks for sharing
Paunescu.Daniel, no problems, man. Best of luck with your project!
Hey, Paul, thank you very much! I'm also glad you find the tech interesting. I hope it has some production future.
Regarding the camera work - very valid crit, man. Thank you very much! Now that you pointed that out it seems really obvious. I'll make sure to keep that in mind for the future!
cool stuff
Thank you very much, moose! You're awesome, man.
Hazardous, much appreciated, buddy!
Huge thanks, cptSwing. I wish I knew.
My first thought was... this sounds like it requires a large number of shader instructions to pull off, which means it's going to hurt performance in a real game level with everything else going on (AI, physics, lighting, etc.). Generally this is why studios use simpler shaders with more textures. But that's just my first impression, I haven't digested everything in here yet.
Your direction is fantastic and this is an impressive project even if your were using Diffuse maps!
(damnit with all those pages stuff gets lost
Adding a diffuse pattern on top is just 2 more instructions. Of course damage blending and sand or snow or whatever cost extra but so far I believe it is comparable with analogous approaches instructions-wise. But you don't have to use all of that functionality. The basic shader is 73 instructions and it covers spec, normal and diffuse with 1 texture. The biggest problem here so far is that because of texture co-compression in UDK you can't put a gradient map into the blue channel of a normal map to have your material described by a single RGB texture. You have to go with RGBA and that is not very economic. But there has to be a way to solve this, I'm just curios to find someone who knows how.
SirCalalot, thank you very much once again. That was the plan and I hope it worked out.
Huge thanks, praetor187. Much appreciated.
Looks like the final instruction count is around 230 or so? Shader complexity is a real barrier these days. It's not just 14 instructions, it's adding this again and again for all those controls. If you're controlling color, normal map, and specular, all with these gradient/height maps, then that can get really expensive. Works great for a portfolio piece that can be rendered out to a video, but usually doesn't work so well for a real-time game that someone is playing.
It's really an unfortunate wall. As an artist I want all these controls and surface details, but I have to dial it back to allow the game to perform well.
Building a complex shader is great as a learning experience. Really helps you understand how far you can push a technique. And you've pushed this one pretty far, looks good! I'm curious how far you could optimize this.
This is a great portfolio piece, don't get me wrong. The optimization part goes above and beyond what most employers are looking for in their candidates. I want to be clear I'm not disparaging your work. It's a beautiful result, and lovely of you to share the workflow so thoroughly! I just want to clarify why this process is not used more often. When it's used, it's used sparingly, because the fill rate cost can get very high very quickly.
Added your thread to the wiki, good stuff d1ver!
http://wiki.polycount.com/Multitexture
About normal map compression. Yeah, just a fact of life I think. So you could either use a single uncompressed file and pack it all into one... R and G for the normal map, B and A for two height maps (is that right?) Or you could use two textures and compress them both... DXT5nm normal map (just red and green stored), plus a DXT1 map with three height maps in it.
Though I'm afraid I've confused you with the shaders. I've got to make a note on that "making of" video or something:)
When I say 73 instructions I mean 73 instructions for a perfectly, fully functional ready-for-use shader and that is with only 1 texture sampled(!), so it is already a pretty nice optimization:
[ame="
[size=-1](I'm sorry to repost the video, I just wanted to link it, since it describes all the materials, but it just embeds all by itself)[/size]
Adding overlayed diffuse component on top is only 2 instructions more.
230 was just an unoptimized version of the shader with both kinds of damage generation and vertex blended sand. Right now this shader performs at 156 instructions, feel free to download it, give it a spin and all the other shaders as well.
All of them are less then Epic used for their vertex painted wet/moss surfaces from foliage map demo. But you definitely don't have to or even shouldn't use the most expensive one's all the time.
Gradient map is used only once to create the diffuse component and then specular, as it usually is, is just a contrasted colored version of the diffuse. So there is no adding it again and again - it's just one single time.
So in all honesty I still believe that this approach has dramatic potential for replacing a big share of our diffuse maps. So far I haven't seen a solid argument against it performing it's purpose less efficient than RGB diffuse map approach. In fact the optimization capabilities surprised even me and pushed to find new ways to comfortably cram more content into gradient maps(hence the PSD file in the video).
And that is with only half-witted me working on it.
So far, if middleware architects like Epic give this a proper integration I'm pretty certain that it could kick diffuse maps ass so hard for too many purposes. I mean, there is a whole environment built using only gradient maps and yet no one could(or would want to - which is even more important) tell the difference.
Considering the NM co compression I also thought I'd clarify 'cause I'm afraid someone might take double "co" as a type-o
So when you try to stick your Gradient Map into the mostly useless blue channel of your Normal Map you get this:
You could try to use default texture compression but that would take a lot of kick out of your normal maps, which is also bad, when you rely on it so much:
Though it could be the way to go since most of the console games are really short on RAM.
So yeah it is the fact of life, but it doesn't mean it doesn't have to be changed.
In an industry that is all about efficiency blue channel of the Normal Map is a downright waste of 1/3 of our Normal Memory budget. Now how can we talk about new technology and more memory when we sit there doing nothing about this black hole sucking on our resources? I know that texture compression is a touchy subject and I perfectly realize that it is hard, but it doesn't mean that It should avoided. It means that the awesome programmers should strap on a pair and give it hell. There's nothing that can't be done I just hope there'll be enough incentive for it.
Or it could be just a UDK issue and you could actually get this sorted out by your good old graphics programming friend - I don't know:)
All I know is that I would love to see artists define whole surfaces with single RGB maps, saving so much money and memory and having time to make their games awesome where they have to be.
Is co-compression your own term, or did you find it somewhere else? AFAIK there's nothing special about what Epic's doing with their compression, it's plain vanilla DXT. Here's some info. http://udn.epicgames.com/Three/NormalMapFormats.html
If you want to store four channels of data, two of them for a normal map, then TC_NormalmapAlpha is probably the way to go. Though it will probably give you a block-artifacted normal map though, just because of the way DXT compression works.
There's really no way to avoid this, unfortunately. If we want to use compression, it's going to be lossy.
More about it here, and check out the PDF for images http://wiki.polycount.com/NormalMap#Normal_Map_Compression
No "co-compression" is not my term thought it is kind of rare. You can find it here for example:
http://realtimecollisiondetection.net/blog/?p=28
Yeah it seems like it should to be plain vanilla DXT but it doesn't behave that way. The very article from UDN you linked says that Normal Maps are compressed into DXT1 But that is what default compression should be aswell, since it is the most economic and widely used type of compression. Yet the TC_Default compression doesn't produce such severe co-compression artifacts as TC_Normalmap does. That's really weird. Yet if they can do it with no co-compression for all their textures but normal maps, I'm sure they can do it for normal maps aswell. Provided enough incentive.
If we would have a single 3 channel texture for Normal Map + Gradient Map with proper compression it should become a no-brainer to replace a lot of diffuse maps with my "procedural" approach in a lot of places. There might even be a workaround this right now, like using Default compression but adjusting your normals previously to compensate for lost contrast. I just hope to get my hands on some awesome graphics programmers sometime soon to get to the bottom of this
The trouble with uncompressed is that it stores only two channels, disregarding much needed third one, so unfortunately it's not an option.
Thank you very much, OBlastradiusO. Yeah I get almost all my highpolies from zbrush. Though when baking heightmaps from complex 2.5d compositions sometimes you might end up with something like this:
Which is not really useful. So in that case I create a heightmap from the normal map in crazybump. It's really neat because instead of global height relations you get local ones, that carry much more relevant diffuse information.
The problems you're getting with TC_NormalMap aren't because of co-compression, it's because TC_NormalMap isn't a compression setting but a pipeline setting. TC_NormalMap gets automatically interpreted differently in the shader, and the engine performs a preprocessing step on it before compressing them to accentuate the normals. It does this so you lose less information on compression, but because the normals are accentuated and then renormalised, information from the red and green channels bleeds over to the blue channel.
Thanks man. You Rock!
Kurt Russell Fan Club, thanks a lot, buddy.
Yeah, that would explain a lot of things. I tried to tinkle in photoshop and udk to try to mimic the effect of TC_Normalmap but so far to no avail. I'm shamelessly trying to bug someone who might be able to know more about this stuff. We'll see how this goes, but if we'll figure this out I'll be more than glad to update giveaway materials:)
Thanks for the idea, Eric, though it could be a different issue altogether. I'll try to investigate and see where this leads us.
cheers!
It has been my experience to not trust Unreal when calculating the cost of your custom node. Primarily because the material editor does a number of optimization under the hood when you are making a material(I believe that it's called folding). However this is completely bi-passed when you use the custom HLSL input. A great work around to this is using Performance HUD or PIX to profile your shader and see what the actually cost of it is.
i don't think it's effecient at all.
Surely pulling info from object normals, vertex colours, world-space positions etc would give you a similar kind of "unique" detail and not impact rendering performance and shader memory as much.
check out some work by bram eulaers or philip k and see the lengths you can go to with a good tiling texture setup using tradition dif nrm and spec/gloss maps. throw on some "procedural" world position/object normal/vertex colour tweaks and you could take it really far, without sacrificing memory in all these other places.
also, unreal is a very unique engine in how it handles certain things. they take a massive overhead cost for their instanced meshes, so it makes sense to take advantage of that as much as possible to actually get somethign back from initially taking that cost. but many engines don't have that kind of feature, so your memory can be spent in many other areas. with good texture streaming, clever optimisation of textures and assets, textures are very rarely a problem in current gen games unless you're building something really left-field like an open world game where you can fly around at 100mph and load 50 square kilometers in a minute.
the biggest problem you'll have is mesh memory, poor LODs and expensive skinned meshes will chow down much more memory and cause many more problems than a few textures loading in a lower mipmap.
just saying, it seems like solving a problem that didn't really need to be solved as far as memory is concerned.
as far as saving time/money in production, would that technique really be viable to a realistic game where phototexturing is a requirement? the amount of mask textures you'd need to get a good amount of material definition, along with the shader cost of setting it all up seems like it'd just push time cost into memory cost, and you'd end up with a game that looked very "samey", took a year to make and had poor frame rate.
i think it'd be far better to have a collection of good tiling textures that are used widely, and use RGB, full colour, masks along with other techniques, to add in variation and detail. or just accept that we're stuck with 90mb +/- of texture memory and be clever about how we build things, keep shaders cheap and effecient, and get some good variation in surfaces. spend memory on lighting and post effects rather, as that'll give you more bang for your buck - shitty textures can be saved by good lighting but not the other way around, for example.
anyway, just playing a little devils advocate, i like what you did and there's some great stuff to think about but i don't believe it's worth throwing away everythign and embracing something like this without thinking about just what we'd get from it and what it'd cost us.
Hey, Rick_D, I have no trouble with you being the devils advocate:) in fact it's fun to defend your ideas. So here goes:
I'm sorry I don't quite follow. Are you suggesting that having another material instance is more memory intense then having another texture? other places? I beg to disagree. The amount of Vram you have on consoles is puny(especially PS3)
http://artisaverb.info/Ditching%20Diffuse/LoU%20Texeleration.jpg
Once again I beg to differ. This generation of game engines is fill-rate driven and pixel shader is almost always the bottleneck. Compare pixel shader with vertex shader instructions for most materials in udk. No LoDs could give you an optimization equal to eliminating a whole texture lookup or a texture pass.
Some more stuff here:
http://wiki.polycount.com/CategoryWhitepapers#Game_Renderer_Articles
http://www.polycount.com/forum/showthread.php?t=50588
http://artisaverb.info/Hygiene.html
I still don't understand what "other" textures you're talking about. There's a single normal+gradient combo and a single combined texture from grayscale masks. And don't forget that you use your masks for multiple materials.
Also it took me 4 months(and yes a lot of the time saved is due to this tech) to produce the whole environment you see on the first page from the ground up including conception and I haven't seen a single person consider it "samey", in fact, until told none of the professional artists who's seen it prior to release had any idea there might something "unusual" with diffuse maps. If the artists see no difference then the audience won't for sure. It's also about choosing your battles, getting anal about every texture when you've got a whole location to make and your audience won't know the difference is at the very least a waste. I'm against "making things for games" mentality. Make games and put your effort where it matters.
But of course you've got to use this tech smartly and it has it's limits.
that's exactly my point. do textures fast, cheap and almost identical visually.
No one said we should. In fact the purpose of this particular thread is to by all means encourage people to propose valid counter arguments to why this isn't feasible. I'm the first one who would like to know.
So far after 12000 views, NVidia engineers reposting it on their blogs and me shamelessly mailing people about it like crazy I'm yet to find one kind soul who can explain why this approach has no merit.
-subbed.
Hi all i'm from Italy it's 2 long years me and a friend are up to make a game and allways stoped the work cuz : -Blender to UDK = S****T (but I dont have 5000$ for 3DsMAX) , Gimp to texture = OMG (PS costs 2 much for me ) , and UDK to materials and stuff = NO GOOD TUTORIAL (only things usefull to make games that seems 5 years old graphics ) , all the people keep the fancy stuff like pure GOLD no one shares ... -.- ' So I registrated here cuz this post is AWESOME 10+ , this guy is a GOD and in 2 years is the first time someone shares a good stuff , so from me u get 10000000000000000 kisses and thanks .
P.S. sorry if I have a bad english .-.
There is a problem when i fully load the package it gives me this error :
[
MISSING FILES :
Can't find file for package 'd1v_ND_Test' while loading ..\..\UDKGame\Content\ProcMat_Demo\d1v_ProcMat_Demo.upk
Can't find file for package 'd1v_ND_Test' while loading NULL
MISSING OBJECT :
d1v_ND_Test.Materials.Base.DetailMap (Check the log to see all references!)
]
I downloaded the .rar extract it in to its own folder then I put the whole folder under udk/UDKGame/Content , even tried to put only the .upk does the same thing and to give it a try i put your mesh in editor and tried to paint just to see how it works Red=more color/contrast+cracks(btw i tried the diferent MAT but the cracks are allways visible cant get them off even tried combos like red+blue and so on ...) , Green=brown stuff , Blue=NONE ?(nothing changes) and Alpha=Sand .
So the question is , is this thing normal ?