Flow Map Painting Script - Early Alpha
polycounter lvl 8
http://www.scriptspot.com/3ds-max/scripts/flow-map-painter
Latest update:
quick overview of the script:
this script is free to use for anyone, both for personal and commercial use, I just ask for credit for my work
the code is not encrypted as well, so feel free to look around in it and see how I did it; if you want to change it, you are free to do so too, again, I just ask credit for all the hard work I put in this (a considerable amount of work, believe me)
this hybrid script/plugin has been created with the express purpose of being able to easily create flow maps, basically another word for vector displacement maps, to be used in game shaders to simulate things like fluids, which have subtle flows in real life, and can not be simulated in real-time, but can be faked by using flow maps in those shaders.
the script works as follows: you initiate the script, and start painting the flow map on the mesh you selected. the flow you are painting follows the direction of your brush strokes, taking into account brush size and speed, which means that the faster you paint, or the smaller your brush size, the faster the flow of the painted pixels will be.
something you need to understand about this script is that it runs on the background code of 3ds max, not photoshop or something; bitmap management and generation is basic, which means noise tends to be a factor, and you have to take into account the framerate of the painter interface; there's only so much the software can handle.
this basically means that a photoshop pass (mostly blurring and smudging) is always adviseable before taking the result into a game engine.
so why didn't I use the valve method, sculpting vertex normals?
well, I explored that method, and it's actually in the planning for the future of my script; a combination of pixel painting and vertex normal sculpting might just be the perfect combination.
I didn't go for it so far though, because vertex normal sculpting depends on the vertices' normals you're sculpting, which means more detail requires more resolution, and the average user doesn't have 16-core machines that can handle processing millions of vertices.
pixel painting on the other hand doesn't need any tesselation, just map resolution, and that's the best reason I can come up with to have chosen pixel painting over vertex normal sculpting.
so how can you use this?
there's a couple of great topics on flow maps here on polycount, that can help you create a shader for flow maps in UDK:
http://wiki.polycount.com/FlowMap?highlight=%28flow%29%7C%28maps%29
[vv]57953448[/vv]
Latest update:
quick overview of the script:
this script is free to use for anyone, both for personal and commercial use, I just ask for credit for my work
the code is not encrypted as well, so feel free to look around in it and see how I did it; if you want to change it, you are free to do so too, again, I just ask credit for all the hard work I put in this
(a considerable amount of work, believe me)this hybrid script/plugin has been created with the express purpose of being able to easily create flow maps, basically another word for vector displacement maps, to be used in game shaders to simulate things like fluids, which have subtle flows in real life, and can not be simulated in real-time, but can be faked by using flow maps in those shaders.
the script works as follows: you initiate the script, and start painting the flow map on the mesh you selected. the flow you are painting follows the direction of your brush strokes, taking into account brush size and speed, which means that the faster you paint, or the smaller your brush size, the faster the flow of the painted pixels will be.
something you need to understand about this script is that it runs on the background code of 3ds max, not photoshop or something; bitmap management and generation is basic, which means noise tends to be a factor, and you have to take into account the framerate of the painter interface; there's only so much the software can handle.
this basically means that a photoshop pass (mostly blurring and smudging) is always adviseable before taking the result into a game engine.
so why didn't I use the valve method, sculpting vertex normals?
well, I explored that method, and it's actually in the planning for the future of my script; a combination of pixel painting and vertex normal sculpting might just be the perfect combination.
I didn't go for it so far though, because vertex normal sculpting depends on the vertices' normals you're sculpting, which means more detail requires more resolution, and the average user doesn't have 16-core machines that can handle processing millions of vertices.
pixel painting on the other hand doesn't need any tesselation, just map resolution, and that's the best reason I can come up with to have chosen pixel painting over vertex normal sculpting.
so how can you use this?
there's a couple of great topics on flow maps here on polycount, that can help you create a shader for flow maps in UDK:
http://wiki.polycount.com/FlowMap?highlight=%28flow%29%7C%28maps%29
[vv]57953448[/vv]
Replies
Nothing shows up? How do I get it to run?
i was working on a title about a year ago that was using valves flow map method for water in sewers, and a solution like this would have been perfect
run the script, through maxscript -> run script... -> select the script
under customize -> customize user interface -> toolbars -> category "FMC" -> there should be a macroscript there
now drag that macroscript to any toolbar that you wish the button to run the script to be
Will run a few tests and reports ASAP, will see how well the script stands up to 'character' models as opposed to flat planes.
....
Some bugs (which I'm pretty sure you're on already, but just a friendly reminder.)
-After I stop painting, and confirm the 'map', I cannot paint again in the same session unless I close the script and start it up again (the script only, not Max).
-It would be great if the Shift Button could act out as a 'smooth' or eraser function to clean the mistake stroke I might do, or maybe create an auto-backup for the script, so I can step back by iterations?
-It would dandy if the script could remember my last settings (where I saved with what name, size, etc)
Let's see what else I can dig up!
announcement!
NEW VERSION IS COMING UP: CODE FIXES!!
edit: the color values were fine, i'm just having trouble properly implementing the map in the shader apparently
what I need you guys to do is to test some maps in an actual shader that works, and see if the flow goes in the right direction, cause I may need to flip the values
The only issue is that sometimes the flow doesn't follow the direction I painted the map in, I'm guessing this is more of a 'limitation' from the flow map itself rather than an issue with the script?
The yellow lines show where it's 'going' and the green show how I 'painted' them. Hopefully, someone else can do another test to cross reference with mine.
I think it's an issue with the script, sounds like the offset value is mirrored or something; i'll adjust the code, test it myself and than re-upload
code update, painting values should now be fixed, if they're not though, my suspisions of what was wrong the first time were wrong and i'll need to go in and re-evaluate the code, so I need tests!
http://www.scriptspot.com/3ds-max/scripts/flow-map-painter
edit 2: another update, color code overhaul!
upcoming update: custom.fx shader to preview in the viewport!
edit nvm, restarted max and all is well now
great stuff
yeah, user-friendliness is what is lacking the most at this point.
I'm basically just programming at this point to get the color values right.
oh, the latest update features FINALLY correct color values on the x and y channels by the way, you should update
about your suggestions: a "smooth" function is something i've been thinking about for a while now, and actually it's been my intention to implement it ever since the first version of this script, when I was still combing normals and baking out normal maps
the eraser is incoming, don't worry, that's soon to be implemented
about settings remember: i'm gonna have to look into that, sounds like a fantastic option
autobackup: i'm gonna implement an option to open previously edited maps, that should actually be pretty easy
among other things, i'm currently focusing on having the material update in realtime in the viewport, instead of having to look at the 2D preview, that I actually just put in to have some kind of idea of what you're painting.
i've also noticed that a map size other than 512 doesn't preview correctly, i'm working on that
keep em coming guys!
But Max 2012, has a nasty habit of 'keeping' WIP textures and leaking said textures, so it will only cause more confusion.
So yeah, it's kinda of a 'forced' situation for the shader at this point.
Tried the script really quick. The "SB" brush seems to be lagging like hell on my machine, the "AB" one works fine though!
Also check this out if you haven't yet. Couple of interesting tools here. They are using splines to control the flow.
http://www.gdcvault.com/play/1015309/Water-Technology-of
about the laginess: sorry about that, but there is really nothing I can do about it; it's the inherent laginess of changing a bitmap in realtime using maxscript. the viewport canvas tool doesn't have that, but it uses a plugin, so it doesn't have to deal with the performance issues inherent to using maxscript.
I am looking into a potential new option that involves using an array of point4's, and converting that to a bitmap upon exiting the code. the problem with that, ofcourse, would be different map sizes; the preview wouldn't work for anything other than the UI item's size, so there's that.
I am seriously considering though just using the canvas tool plugin code and adjusting that in C++ to suit my ends; it wouldn't have to deal with performance issues and it opens up hundreds of new possibilities, together with taking away limitations, and making realtime painting in the viewport a real possibility.
that, however, will have to wait until I know that it's really necessary. for now, i'm gonna tweak the maxscript code until it gets decent results when used with the performance issues in mind
i've tested it on a much more powerful computer now, and it seems to work a lot better, so computer power is one thing that you need to take into account here.
also, as long as you put in your strokes with maxscript's laginess in mind, you shouldn't have a problem
aside from that, i've started looking into the C++ code required to paint in the viewport in realtime, and it doesn't seem all that different from it's maxscript counterpart. I will definitely look into it, expect to hear more about it very soon
Anyway I did a basic flow map to check out the tool itself. First of all; am I supposed to be getting live feedback on the model or do I only paint a blank grey mesh and watch the updates in the window?
Opps just re-read the txt file: "in the future, a custom shader will be delivered with the script that will preview the flow map in real time,
so you don't have to convert complicated color values in your head."
I like the complicated colour values! I can read them much better than some moving squares so that option will be greatly appreciated. (its also helps me see clearly if I have missed any spots
I tried to apply the flow map to a blinn, then put the blinn on my flow map model then try to paint the flow map in hopes that I could get the colour feedback right on the mesh. It didn't work
(I'm used to painting flow maps onto a UV texture in a 2d program, so painting in 3D is a great asset as it will allow me to break up my texture map into chunks.
Another thing I noticed (though its kinda specific to what I know from working with flow maps) is that the blue channel is 0. It might benefit having the option to add a clouds/noise to that channel. That way the channel can be used to break up the flow repeat timing thing so the whole thing doesn't repeat at once giving a horrible visual confirmation of the shaders blurry transition. If this makes sense.
I haven't had the chance to make a flow map shader yet so I can't test out how it works so I'm looking forward to your supplied shader
I use those in our shaders to save texture memory, as a byproduct we get some decent interpolation as well.
the viewport feedback of your flow map is actually the biggest problem I have right now. for some reason, maxscript doesn't allow me to access or set a bitmap value in the diffuse map slot of any kind of material whatsoever.
i'm using theMaterial.diffuse.bitmap = theBitmap, or something similar to set the bitmap, but maxscript just gives an error and says that it doesn't recognise the command or something.
in any case, I'm thinking this will soon not be a problem anymore, since I've decided to switch to C++ again, because performance is the biggest issue, even worse than the material problems, and I just can't have that
@mbknielsen:
yes, that was my first though actually. the visualisation is a nice addition, but the script would again stop working around a certain amount of vertices, which, again, as I said before, I simply can't have
also, pixel painting allows for the best amount of detail, like small sub-streams in rivers, which is actually what flow maps are for; you have probably noticed that they're not as good at painting BIG flows as a classic scrolling texture is
from what I figure, flow maps are all about the details, and vertex colors just don't do that
in any case, you guys can keep testing the script, I uploaded a new version yesterday, that has a 0,5 value in the blue channel, but only on the pixels that have been painted. you could use this as a mask, combined with an intensity controller for the offset intensity
so the biggest announcement right now is that instead of a maxscript, the painter is going to become a full-fledged PLUGIN, so that means a .dll file.
DONT WORRY THOUGH
when it's all finished, I still plan on releasing the whole thing open source, with all the files in the visual studio solution included, as a gesture to the community
Good job my good Sir!
I'm starting to feel a bit special at the moment after ten minutes of running the script in different ways and seeing nothing happen in Max 2011
http://www.scriptspot.com/3ds-max/scripts/flow-map-painter
edit: thought i might give you guys an update on the status of the project; i've been working on artwork during the week, and weekends have been reserved for the flow map painter
i've decided to go for a hybrid project, where C++ deals with the CPU intensive parts and maxscript simply interfaces with it. the goal is to keep the user friendly interface that maxscript offers, and still have performance of the functionality.
writing a maxscript plugin isn't as hard as writing a full on modifier or utility plugin, so I think you guys should be expecting something more pretty soon
Bravo.
that sounds like a really good idea! i can't wait for the final thing!
updated my script, apparently the colors were still off, so now they should be correct
also, little update: the test shader has been created, so I will be uploading that with the final version, but you won't have any use for it now so there's no use in uploading
about the plugin: still working on it don't worry, the SDK is just giving me massive headaches, and we're in crunch time at work so that is slowing things down considerably...
other than that though, I would like some more artist requests other than actually make everything work;
i'm thinking about adding a functionality that lets you paint "additively" meaning you add to the color already there instead of painting over it.
also, a "blob" brush is one of the points on the agenda, effectively giving you guys the tools to create upwellings with the direction of the water going away from the center of the "blob" you paint, creating some sort of uwelling bubbles or something.
also, just to confirm: the blue channel will be used for delivering a mask to the user, (it'll be completely white, and all that's not been painted over will be black),
and it will also be used to create a foam mask, so you guys can fake transitions between different flows.
but that is stuff for later, right now i'm still trying to get my solution to compile...
I don't have any assets right now that need flow maps for them. But I will still have a play around with it.
Can't wait to test this baby out on some epic scenes!
also, i've decided to upload my shader anyway, since you guys could probably find some use for it
it's a .fx file, and you can use it in 3ds max; to see the animation you'll have to drag the timeline slider along. also, I suspect you could possibly load it into udk and use it there, but I haven't tried that yet.
i'll give the link again:
http://www.scriptspot.com/3ds-max/scripts/flow-map-painter
don't forget guys, i need you to test this thing and i need suggestions!
I made a thread a while back on the subject when I wanted to know more.
by using this flow map in a shader designed to incorporate it, one can thus create the impression of subtle flows on liquid surfaces such as water, lava, or others.
flow maps at this point of the technology are not really used much, since it means yet another texture has to be loaded. however, it is one of the upcoming new types of map, and as I mentioned, it has two unused channels which can potentially be used for more masks, which is always a good thing.
as of this point though, creating flow maps has been incredibly tedious, and only studios like valve have been able to create them in a relatively easy manner. (as far as I k now, I have heard of a couple others though, but i can't recall which ones)
the point of my script is to be able to actually paint them in the viewport of 3d studio max, which, at this point, it already does, just not with any kind of performance, which is why i'm working on a plugin so that c++ can take over the heavy parts and i can let maxscript handle the easy parts.
Im not actually a max user anymore but good job on this project regardless!
my plugin has finally reached a phase where I can actually give my functions the data they need and have them return processed data in a format i want (took a while to figure out how to return anything other than a true or false, value, but as of now, i can also return bitmaps, and pretty much every value maxscript itself has), so that means my plugin is almost ready for a test run inside my script and test whether or not i've made any progress on the performance front.
i'm not entirely sure that i'll be able to do that this weekend, but I just wanted to let you guys know that this project hasn't bled to death
problem is that i'm also working on my portfolio very hard, since my internship at larian is nearing it's end and I need to start sending out applications
today, I got my c++ code to return a bitmap with pixels that were changed at certain coordinates, which means that I can already pass coordinates that need to get changed colors to max, which in turn means that I can do most of what I was looking for in C++.
BUT currently I have some trouble optimising the code, and adding features like the 'bulge' brush that creates some kind of bubbling up effect, with normals going away from the center;
at the moment my biggest problem is that the code creates a new bitmap and returns it for every tick of the brush, but doesn't delete it, which means that after a single tick with a radius of 50, the code has already created quite a lot of bitmaps in the memory, which ofcourse makes max crash... i'm working now on directly writing to the bitmap that gets changed, as in the actual file, not just return a bitmap to max.
as for some info that is actually relevant to you guys: as soon as I get that little bit of code working, I can start putting my plugin out there for you guys to test, so you can be expecting something very soon now
Having a brush like this will fill the area you are painting on better and perhaps even reduce some of the stepping.
the slow performance is the result of maxscript not being able to handle realtime alteration of bitmaps; maxscript is basically a way for the max user to tell the source code what it has to do, but that means that the source code has to compile the scripting commands first and then execute them, which is a lot slower than just writing the source directly, which is actually the cause of the laginess.
you may wonder "hey wait, doesn't the canvas paint tool paint directly in the viewport with incredible performance?" yet it does, but it is a plugin that handles the heavy parts, not maxscript, hence the performance
as for the brush, yes I have thought about that, and it is on my list, but for now I just want to get my C++ code to actually work before I start worrying about that kind of thing. at the moment I can not yet set any color values in realtime (as a matter of fact, my latest build crashes max when I use it), but I am slowly but surely closing in on the solution.
one other thing that i want to mention is that I plan on implementing smoothing: instead of just sampling two points to calculate the color, the code will remember five or ten points, and smooth the colors out over them, creating a lot nicer result with less noise. getting that data will also enable me to draw a line of points between points that have a high spacing (hence, where the code skipped a point), and so fill up the gaps when painting fast.
but again, the hard part at the moment is actually getting my code to work, so be assured that all that stuff is on my list, but it's just not a priority right now
The smoothing thing sounds good
little update on the part of getting something to show up when painting: I got that part working, but I can't get the color to properly transfer from the mathematics to the painting part of the code; in theory it's simple, but the practice seems to be quite hard.
the problem i have right now is that I have to store an AColor variable in a BMM_Color_64 variable, for the people that have worked with the SDK;
sidenote: Paintcolor is an AColor variable that gets declared outside of the function, which is more performant because it won't have to declared and destroyed 50 times per tick of the brush.
this part is where it goes wrong. without those last three lines, the code compiles fine, but the painting color in max is black, because no actual color value gets stored in the p64 color. (that is the color being used in the PutPixels function that actually changes the pixels, hence the painting part)
but if I put in the last three lines of this code snippet, then the solution refuses to compile, even though I have directly copied this manner of working from the SDK HowTo solution named paintertexturesample, should any of you want to check it out.
I am now reaching out to you guys to help me solve this problem: I have no idea how to solve it, as I have included all the header files that are necessary (i'm pretty sure I included some that aren't necessary, but that's cleanup for later), and I have checked an re-checked the howto example and I can't find where it goes wrong on my end.
the compile error says
"FlToWord: identifier not found"
some help would be greatly appreciated, because if I can solve this then the plugin comes VERY close to being fit for uploading for testing
ps: btw, I can happily report that the performance issues have been solved by C++: due to the painter interface's inherent lagginess, some points still get skipped, but my smoothing will solve that once I implement it. other than that, I have not been able to get it to lag as significantly as it did before
pps: I realise the snippet of code is not much to go on, but unfortunately the 3ds max SDK source code is copyrighted by autodesk, and I don't want to take any chances
I installed 3DS Max back on my machine just so I could use it!
well there's good news too: aside from a few kinks, EVERYTHING WORKS NOW! which means that as soon as I get the color conversion to work properly, i'll be releasing the plugin for you guys to be used, with an updated (better structured) version of the install manual, and again, the custom shader is already in there so feel free to use it!
stay tuned for more guys, we're closing in with the end in sight here
right guys, it's here. the plugin painting works, even though the color values are still off and wonky stuff happens when maximum color values are reached. for now, paint in short brush strokes, short meaning around two times the width of the map before you start reaching max values. again, flow maps are about subtlety, but I am aware that the current functionality isn't there yet. hang in there, i'm working on it
I have updated the .rar file on scriptspot with the current version of the script, the shader, and the plugin file included, and an updated version of the installation and usage help textfile. if you still have questions, please post them here, and as always, I need testers!
note on the image: i have cheated here and manually applied the painted bitmap to the mesh, but other than that it's exactly like the script created it.
I'll check this bad-boy out when I get home!