Thanks, slowly moving towards a more and more decent result Although how fast I do the stroke motion seems to affect the direction, which is making it difficult to paint accurately in detailed areas. Also the paint radius in the viewport seems to be much smaller than the strokes that get painted on the map, which also makes it hard for small detailing.
it's good that you mention that. i probably divided the brush radius by 2 somewhere, to get the radius of the brush, but i probably already pass the correct value from max, so it's half size. I'll fix that, thanks for pointing it out.
and yes, the speed of the brush stokes does affect the direction; the direction gets more intense the faster you paint, or at least it should get faster. remember though, the script/plugin runs on the built-in painter interface, which can only run/sample brush positions at a certain framerate, that I can not influence without writing my own interface in full C++, which is something I am not able to do
stroking quite slowly with this is advised, and even then, a photoshop pass will still be needed; go over your brush strokes with a soft smudge brush, in the direction of your strokes. this also smooths out all the noise in the map.
also, remember to save as a 32 bit map, 16 bit gets a lot of pixelation.
Okay, but as it is now, I have to do really quick strokes to get it to flow in the direction I paint, if I do slow strokes it flows in a completely different direction. So it would be nice to be able to toggle if the stroke speed affects anything, and maybe have set the direction and speed manually. Also, being able to bucket fill the whole map with a desired general flow direction would also be nice
Okay, but as it is now, I have to do really quick strokes to get it to flow in the direction I paint, if I do slow strokes it flows in a completely different direction. So it would be nice to be able to toggle if the stroke speed affects anything, and maybe have set the direction and speed manually. Also, being able to bucket fill the whole map with a desired general flow direction would also be nice
hmm... never had that before, strange, that should not be happening. are you sure you saved your .tga map as 32 bit before loading it into UDK? i've noticed the shader starts giving weird directions if that hasn't been done
about the bucket: great idea! that's definitely something to come
This might be a stretch, but how about a 'compass' of sorts in the interface?
When it's in the 'North' position, you paint as usual. But when you move the needle, say 45 degrees to the right, it rotates all of the flow directions already painted to 45 degrees clockwise of their original values.
So even after you've painted your flow map, you can still tweak the overall flow directions on a global scale
yes you did, but as far as how to handle that practically, i'm currently at this stage:
seriously though, there's a ton of other stuff I have to fix first, so i'll make sure to put it on the checklist of things to do, but don't expect it any time soon
seriously though, there's a ton of other stuff I have to fix first, so i'll make sure to put it on the checklist of things to do, but don't expect it any time soon
Haha, no worries!
I'm just throwing ideas out there
So here I made 3 strokes from left to right with different speeds, and exaggerated the result in photoshop. When imported to UDK they all flow in different direction, where none go directly from left to right. The texture file is a .tga using TC_Default for compression
ah well that's what the photoshop pass is for it might work that way i'll certainly solve that issue in the future, it might very possibly only require the changing of a single line of code
you guys have given me a lot of ideas, and going further from your suggestions i'm in the process of redesigning the whole interface to accomodate the requested functions that I deem very useful (among others the compass). I might release small updates before I start on the new interface, but i'll probably just release a big one again that's gonna take longer than small ones, but it's going to be worth it
ok, i'll do that so you want the radius being disconnected from the color values right?
the reason I put that in is because the values kept being incredibly subtle, and i couldn't manage to get a high flow speed on low brush radiuses. the brush smoothstepping isn't fully perfectly functional yet, so high speed painting was not an option either
that's why I coupled the radius to the color values, so you get more speed the lower your brush radius is.
I do see why that would be impractical though, so i'll make a fix where the spinner value for overall intensity actually does something, and take the brush radius out of the equation
as per your request, i took the radius out of the equation and edited the algorithm so now you should be painting pretty accurate colors
keep in mind that the offset is still a factor. i'm working on a conversion for the offset to just give the direction, and the intensity of the color to be calculated by the users's setting for intensity, but that's a bit hard since the magnitude of the offset is a large factor in actually calculating the appropriate color, and changing values actually changes direction... i'm probably gonna go for the current R and G calculation, and store the speed in the blue channel, and the mask in the alpha.
that'll be for the big update though; in the meantime, enjoy
skimmed this thread real quick, I don't think anyone mentioned this:
the script doesn't seem to work in running the Nitrious display divers(i know right? who uses that shit) - switching to Direct3d drivers fixed it.
skimmed this thread real quick, I don't think anyone mentioned this:
the script doesn't seem to work in running the Nitrious display divers(i know right? who uses that shit) - switching to Direct3d drivers fixed it.
Thanks for the script btw, truely awesome!
that's because nitrous doesn't support DirectX shaders nothing I can do about that, as nitrous is basically a shader by itself.
allright guys i've been working really hard on the script the past few days; as an answer to your question, Ace-Angel; no, i'm afraid it doesn't work for max 09; for now it only works for 2012 and up, but i'm working on getting it max 10 and 11 compatible as well. the problem is that the directory structure of the SDK changed between the 11 and 12 features, and compiling for the 11 version with the code that has been written for the 12 version creates more problems than I care to admit, even if I do get the header file structure right.
I'm about to release an update, it will be online somewhere today, so if any of you are still interested, keep your eyes peeled on this thread, some exciting stuff has been put in
big user friendliness update this time, with a massively improved functionality for creating new flow maps, and loading in previously created ones, featuring automatic searching for flow maps in the given directory, and making it really easy to manage all your flow maps
it should work on 3ds max 2012 and up, depending on whether or not autodesk changed the SDK file structure in between those versions or not, like they did in between 2011 and 2012. You're welcome to try it out, but I only have 2012 installed on my computer i'm afraid
this time around I massively increased the functionality, and changed much of how the script works. Also, I'm working on a tech demo to showcase the new features, but for now just go ahead and try it out
not everything is gonna work, but your average button shouldn't crash the script
just don't mess around with the buttons in the layer rollout too much, they don't work properly yet
biggest features this time:
- dockable UI!
- per-pixel vector calculation for more fidelity, higher smoothness and more quality overall!
- dynamic interface to quickly be able to scroll through your previously created flow maps, including a dynamic preview bitmap, and extra information about the selected flow map
- dynamic layer interface is in the works, with the ability to add and remove as many layers as you want! currently this is not yet working fully, but if you don't touch the buttons you'll be fine.
I just uploaded a new version by the way, small bug fix: when you start painting now, you don't have those black or dark blue dots anymore (the initial offset calculation didn't account for the current position and the last position being the same when you start painting, now it does)
Ah okay after i try it in 2013 it doesn't work. It give me runtime error when i pick and object, and the Button icon doesn't showed up
I'll try to get that fixed, not sure what it's caused by. It doesn't sound like a plugin problem though, that part of the script doesn't use any C++... that being said, they may have changed some maxscript functions in between 12 and 13, who knows... also, be sure to put the icons in the correct folder, and all the files where they should - the script will behave weirdly otherwise
In the meantime, i've released a new tech demo for my script, here you go:
hey the error in 2013 has something to do with a change to the isolate selection function that is different in 2013. I founf a script that "fixes it" but it still gets error. maybe you can use this new script and make a change and it works? here's the max script I found: Isolate Selection legacy Mode for 2013
Maybe you are already aware of that, sorry if I am dumb cheers
-- Runtime error: No such macro-script: Isolate_Selection
hi, thanks for pointing that out to me, i hadn't had the chance to test my script in 2013 since I don't have an installation for it, but now that I know where the problem is, I can make a solution this is actually fairly simple to solve, so I will upload the fixed version later this week
have you got code in there to account for uv shells that are oriented in different directions?
i have a project in mind and really haven't a clue on how to deal with things like that so was hoping to lift some code from somewhere (properly credited of course)
have you got code in there to account for uv shells that are oriented in different directions?
i have a project in mind and really haven't a clue on how to deal with things like that so was hoping to lift some code from somewhere (properly credited of course)
the script uses the existing UV coordinates on your mesh - so if you have a proper unwrap ready, anything fancy like UV shells shouldn't pose a problem
the script uses the existing UV coordinates on your mesh - so if you have a proper unwrap ready, anything fancy like UV shells shouldn't pose a problem
I'm looking at a way of painting tangent space normal maps in the viewport so the orientation of UVs is important - I figured you'd need to account for something similar in your stuff. no worries though - it's all possible, I just need to figure out how the sums work.
Is it just me or is this great tool really not compatible with 2014?... I receive a DLL error on startup(culprit being the plugin file), and the Isolation MXS error while selecting an object.
Is it just me or is this great tool really not compatible with 2014?... I receive a DLL error on startup(culprit being the plugin file), and the Isolation MXS error while selecting an object.
Really wanted to give this a try.
Even if you could get the plugin working in Max 2014, I don't think there is any way the custom viewport shader would work. Autodesk messed with the DirectX system in their two latest versions, so shaders simply don't work.
You'd be better off getting a copy of Max 2012 to use for tasks like this.
Wow I really didn't expect this thread to come back to life sorry for the extremely late responses!
@Minato: the DLL was compiled for max 2012 yes. Sadly to get this tool working in any acceptable capacity I had to move the heavy calculations to C++, seeing as neither maxscript nor dotnet can work fast enough to update bitmaps and reload them in realtime. (even C++ has problems with it) This of course also means that for every version of max, in order to get the tool to work, you need a newly compiled dll for the new SDK. Seeing as Autodesk isn't great on the backwards compatibility front, this is quite hard for me to do.
@rs3d: I bet there is, but if there is, I haven't found one yet. I'm not very experienced with offline rendering in max, but if you can create a material that has a vector map node, which would then go into some math nodes, then yes, it's likely you can create an offline-renderable material with these maps.
Replies
it's good that you mention that. i probably divided the brush radius by 2 somewhere, to get the radius of the brush, but i probably already pass the correct value from max, so it's half size. I'll fix that, thanks for pointing it out.
and yes, the speed of the brush stokes does affect the direction; the direction gets more intense the faster you paint, or at least it should get faster. remember though, the script/plugin runs on the built-in painter interface, which can only run/sample brush positions at a certain framerate, that I can not influence without writing my own interface in full C++, which is something I am not able to do
stroking quite slowly with this is advised, and even then, a photoshop pass will still be needed; go over your brush strokes with a soft smudge brush, in the direction of your strokes. this also smooths out all the noise in the map.
also, remember to save as a 32 bit map, 16 bit gets a lot of pixelation.
hmm... never had that before, strange, that should not be happening. are you sure you saved your .tga map as 32 bit before loading it into UDK? i've noticed the shader starts giving weird directions if that hasn't been done
about the bucket: great idea! that's definitely something to come
When it's in the 'North' position, you paint as usual. But when you move the needle, say 45 degrees to the right, it rotates all of the flow directions already painted to 45 degrees clockwise of their original values.
So even after you've painted your flow map, you can still tweak the overall flow directions on a global scale
Did I explain that well enough?
seriously though, there's a ton of other stuff I have to fix first, so i'll make sure to put it on the checklist of things to do, but don't expect it any time soon
Will do some more tests and be sure to save as 32-bit .tga this time.
will do
I'm just throwing ideas out there
Keep up the awesome work, dude.
edit: forgot picture
you guys have given me a lot of ideas, and going further from your suggestions i'm in the process of redesigning the whole interface to accomodate the requested functions that I deem very useful (among others the compass). I might release small updates before I start on the new interface, but i'll probably just release a big one again
the reason I put that in is because the values kept being incredibly subtle, and i couldn't manage to get a high flow speed on low brush radiuses. the brush smoothstepping isn't fully perfectly functional yet, so high speed painting was not an option either
that's why I coupled the radius to the color values, so you get more speed the lower your brush radius is.
I do see why that would be impractical though, so i'll make a fix where the spinner value for overall intensity actually does something, and take the brush radius out of the equation
as per your request, i took the radius out of the equation and edited the algorithm so now you should be painting pretty accurate colors
keep in mind that the offset is still a factor. i'm working on a conversion for the offset to just give the direction, and the intensity of the color to be calculated by the users's setting for intensity, but that's a bit hard since the magnitude of the offset is a large factor in actually calculating the appropriate color, and changing values actually changes direction... i'm probably gonna go for the current R and G calculation, and store the speed in the blue channel, and the mask in the alpha.
that'll be for the big update though; in the meantime, enjoy
the script doesn't seem to work in running the Nitrious display divers(i know right? who uses that shit) - switching to Direct3d drivers fixed it.
Thanks for the script btw, truely awesome!
that's because nitrous doesn't support DirectX shaders
and yes, nobody should use that
allright guys i've been working really hard on the script the past few days; as an answer to your question, Ace-Angel; no, i'm afraid it doesn't work for max 09; for now it only works for 2012 and up, but i'm working on getting it max 10 and 11 compatible as well. the problem is that the directory structure of the SDK changed between the 11 and 12 features, and compiling for the 11 version with the code that has been written for the 12 version creates more problems than I care to admit, even if I do get the header file structure right.
I'm about to release an update, it will be online somewhere today, so if any of you are still interested, keep your eyes peeled on this thread, some exciting stuff has been put in
big user friendliness update this time, with a massively improved functionality for creating new flow maps, and loading in previously created ones, featuring automatic searching for flow maps in the given directory, and making it really easy to manage all your flow maps
download it here:
http://www.scriptspot.com/3ds-max/scripts/flow-map-painter
the previously posted video still counts, by the way: the main function of the script hasn't changed, only it's useability and user friendliness
I would sincerely like some feedback, to see if everything is intuitive for a first time user
screenshots:
it should work on 3ds max 2012 and up, depending on whether or not autodesk changed the SDK file structure in between those versions or not, like they did in between 2011 and 2012. You're welcome to try it out, but I only have 2012 installed on my computer i'm afraid
http://www.scriptspot.com/3ds-max/scripts/flow-map-painter
this time around I massively increased the functionality, and changed much of how the script works. Also, I'm working on a tech demo to showcase the new features, but for now just go ahead and try it out
not everything is gonna work, but your average button shouldn't crash the script
just don't mess around with the buttons in the layer rollout too much, they don't work properly yet
biggest features this time:
- dockable UI!
- per-pixel vector calculation for more fidelity, higher smoothness and more quality overall!
- dynamic interface to quickly be able to scroll through your previously created flow maps, including a dynamic preview bitmap, and extra information about the selected flow map
- dynamic layer interface is in the works, with the ability to add and remove as many layers as you want! currently this is not yet working fully, but if you don't touch the buttons you'll be fine.
some eye candy for your consideration:
it should, but I haven't tried it yet
I'll try to get that fixed, not sure what it's caused by. It doesn't sound like a plugin problem though, that part of the script doesn't use any C++... that being said, they may have changed some maxscript functions in between 12 and 13, who knows... also, be sure to put the icons in the correct folder, and all the files where they should - the script will behave weirdly otherwise
In the meantime, i've released a new tech demo for my script, here you go:
https://vimeo.com/57953448
[vv]57953448[/vv]
enjoy
Isolate Selection legacy Mode for 2013
Maybe you are already aware of that, sorry if I am dumb
-- Runtime error: No such macro-script: Isolate_Selection
thanks!
have you got code in there to account for uv shells that are oriented in different directions?
i have a project in mind and really haven't a clue on how to deal with things like that so was hoping to lift some code from somewhere (properly credited of course)
the script uses the existing UV coordinates on your mesh - so if you have a proper unwrap ready, anything fancy like UV shells shouldn't pose a problem
I'm looking at a way of painting tangent space normal maps in the viewport so the orientation of UVs is important - I figured you'd need to account for something similar in your stuff. no worries though - it's all possible, I just need to figure out how the sums work.
Really wanted to give this a try.
Even if you could get the plugin working in Max 2014, I don't think there is any way the custom viewport shader would work. Autodesk messed with the DirectX system in their two latest versions, so shaders simply don't work.
You'd be better off getting a copy of Max 2012 to use for tasks like this.
@Minato: the DLL was compiled for max 2012 yes. Sadly to get this tool working in any acceptable capacity I had to move the heavy calculations to C++, seeing as neither maxscript nor dotnet can work fast enough to update bitmaps and reload them in realtime. (even C++ has problems with it) This of course also means that for every version of max, in order to get the tool to work, you need a newly compiled dll for the new SDK. Seeing as Autodesk isn't great on the backwards compatibility front, this is quite hard for me to do.
@rs3d: I bet there is, but if there is, I haven't found one yet. I'm not very experienced with offline rendering in max, but if you can create a material that has a vector map node, which would then go into some math nodes, then yes, it's likely you can create an offline-renderable material with these maps.
About the recompiling - please ask Dave from maxplugins.de. He compiles a lot of the older plugins for new max versions, so this might be helpful...