matt, have you considered doing a 'save to library' option that exports a selection to a new max file and creates the thumb. could be a nice quick way of saving stuff as you work.
I'm not saving any max files with this tool though, just saving out jpgs now, so u can see whats in a max file when merging without having to open it and search through it manually and unhide layers/ect.
finally finished a set of C#, python and max scripts to establish 2 way communication between python and 3ds max (thanks blur for taking down your 3ds max/python stuff ). First I tried COM objects but this didn't prove practical because I had problems with multiple instances, python Qt windows never stayed on top of 3ds max, registry access issues (reg access is blocked for regular artists here).
Sockets...I was too stupid for that couldn't get it to work.
But with named pipes I got it to work. So now we can launch python scripts with UI and make them talk to max and vice versa.
Almost done with this.... finally :P. Got it all working now, seems solid.
I just want to try and get better camera angles for the pieces if I can, which I think all I need to do is learn/figure out how to set each Objects Local Pivot's Y to Straight up (Z) , and use this look at controller setup to look at the perspective camera.
I also would like to get a progress bar working right, like the green install bar, that moves along, but I'm not sure I can do it properly with my setup.
anyways...
I'm thinking I should have my tools updated within a couple days or less. Maybe even tomorrow.. we shall see..
...I'll just say it's hard to find fairly new PyQt versions with a working SQL module for 9 different versions of Maya....but I think I succeeded now I just need to convince our clients to stop using really old software...
- Added the Merge Geometry Preview, which is seen just above the last post. I have a video demonstrating it on the site as well.
- UV Vert to Mesh Vert - Converts a UV Vert Selection to a Mesh Selection. It will take the UV Vert selection, collapse the stack and have the verts selected for you.
I've also Fixed some random issues and such. You can see the bug list on scripts page as well.
(almost) finished... now we have a framework (python modules, max files via filein, C# dll file for max) where we can run the same python program with python GUI in 18 different flavors of max (2011 - 9.0) and maya (2011 - 2008) both 32 and 64 bit. (still working on 8.5 - we still have clients who use this )
Now we have much less of a code base to maintain! Most of our new plugins will have the majority of their code in Python, with the option to easily port them to Maya. This is especially useful for scripts which are theoretically app independent (e.g. file management, naming conventions, etc, etc)
Changes inside the python code are very very few to adapt a program to work with max or maya. All you need to do is use an if statement and then either write maya python/mel commands or dispatch your commands to max.
A standard header and footer has to be included into your python code which calls some commands to set up everything - there's usually nothing to change here for the TA when writing a script.
Communication is 2 way - trigger max functions from Python or trigger Python functions from Max.
Such programs run directly inside Maya and via max we use named pipes for inter process communication. Named pipes functionality can also be used from within Maya, allowing us to code a stand alone programs in C# or in a certain Python version where we have certain modules which we do not have in this Maya version.
Also we can write apps which talk to different (3D) apps at the same time. i.e. we could write a connector app translating stuff on the fly from Maya to Max (e.g. create a box, it creates one as well in Maya).
Per default one can use Qt, pyODBC and ctypes in such python scripts and expect them to run on all supported apps. Was quite some work getting all those modules together for x86 and x64.
having fun with window handles... we want to pair stand alone scripts with Max/Maya and launch them from there as well. However the user experience should be as if those scripts were run directly from maya or max.
So I've been looking that the Qt UI minimizes when the 3D app minimizes, that it stays on top of the 3D app while you work with it, etc. works pretty nice
I'm using "named pipes" to have two processes talk to each other. The python script hosts the named pipes server. For max the named pipes client is implemented as C# dll. The UI is then coded in python using Qt. Therefore we can run those scripts natively in maya too!
There are utility python functions which allow you to easily code apps which run either natively in Maya or talk via named pipes to max. This is especially nice for GUI frontends or database connectivity or P4 stuff - code once, use on many platforms.
However, lets say you need python modules with are not available for your maya version (often the case with x64), then you can also use named pipes, because we implemented a named pipes client in python for maya too.
e.g. you have a super image manipulation module, but it's only available for python 2.6 x86 and you're running Maya 2009 x64.
You could probably use sockets as well instead of named pipes, but I ran into problems with that....maybe I was just not clever enough to figure it out.
Right now we're working on cosmetics. since the python app is, when not directly launched from maya, a seperate process, it doesn't minimize with the app that launched it, it's ALWAYS in the foreground (should be in the background when the launching app (e.g. e3ds max) is inactive, should be in the foreground when it's active), etc.
This example uses gpu raycasts to test visibility of the surface to an area light, the textures on the left are the scene triangle lists uses for raycasting.
Started looking into C# in 3DS Max. Using his .dll I was able to make my own .dll in C# in VS 2010, and get a form to appear on Load in Max, as well as print to the listener through C# and execute an existing function of mine written/loaded in MXS. Very cool stuff
Yeah chromatic aberration :P Its vertex distortion in shader, the world is actually flat. In the future I will have the world loop so you can actually walk "around" the moon.
rooster, you will hit lava so you cant dig all the way through :P Note that the screenshot is an extreme example with a small radius, an actual level would be quite a bit bigger.
The technical side is awesome really, but I've difficulties to see what you can build on the moon ? I mean is it a creative game only, or is there some crafting planned ?
Maybe you could add a bevel to the exposed block corners to make everything look a little smoother... but I'm sure others would prefer the crisp, cube-y look. Since Unity can handle more geometry than Java, though, it might be nice.
BeatKitano, Right now its pretty much just building. In the future I want to implement a component based vehicle creation system, crafting, and team based gameplay.
Vrav, I dont want to up the triangle count anymore. It has to rebuild at least 1 8x8x8 block cell every time someone modifies the terrain. Plus when I do stuff like baked indirect lighting and crumbling it will have to update them even more.
BeatKitano, Right now its pretty much just building. In the future I want to implement a component based vehicle creation system, crafting, and team based gameplay.
Vrav, I dont want to up the triangle count anymore. It has to rebuild at least 1 8x8x8 block cell every time someone modifies the terrain. Plus when I do stuff like baked indirect lighting and crumbling it will have to update them even more.
Ahah, my first thought after seeing the last video
And the best part about those gasses (for the most part) is that you cannot see them, so the clients don't need to know every block there's air on, they just need to know that they're suffocating.
any calculations can be done completely server-side
Keg, I plan on sort of doing a blured direct sky light coming from the up vector. So I would first caclulate what voxels can see directly up infinitely. Then in another pass I see what voxels that are in darkness are next to a voxel in light and then transmit some light from the lit voxel, then keep doing that for about 8 passes.
It sounds like a lot of processing, which it is, but after the first initial terrain generation only cells under the modified cell and their neighbors need to be updated, plus once the direct light at the position of the modified block hits a block, cells under that block dont have to be updated. It would have to be updated over multiple frames though, which is ok, and could be done server side. I think this is how its done in Minecraft.
figured this fits here more. Been implementing some post processing shaders for the engine I am working on. After some headaches I managed a solution that worked with the data I have available. Still need to render the ambient occlusion to a lower res texture and potentially apply a blur depending on how things are needed.
rewrote my Unity export script that basically wraps multiple objects automatically into different file containers. I just hate how unity itself often clutters with OBJ or FBX files and I wanted a bit more structure so I can update specific objects or subparts without Unity forcing to work scene wise in 1 max file.
I just select a bunch of objects in max and based on their name it groups them into different groups with a name preview. There is also a heap delay because I noticed that buggy max crashes sometimes because some of the exporters is hanging or taking longer and not responding back to MXS.
anyway nice single button solution for updating models in Unity
hey this looks pretty ace! are you going to release if when its done? as much as I like unity but this would really speed up the annoying update process
Started another new game today :P Basically its a multiplyer shooter similar to quake3 but with a lot more focus on movement with acceleration and wall jumping and stuff.
I'm working full time on my first game at the moment, an arcade style racing game, one of my favourite genres.
Here are a couple of screenshots. Please ignore the crappy UVs and horrible road texture, this is just a test to see the design of the track and test the car handling etc. The car is going to be reworked too, as I made it without blueprints, and also forgot mirrors.
This is a full res shot, the next ones are half res.
Because it's an arcade style racer, I'm purposefully not referencing real car physics. I'm simply making up the physics and handling, and tweaking it till it feels right.
As you can see from the screenshots, I'm actually using soft body dynamics rather than solid body dynamics. Mainly because it's something I have more experience with, and I quite like the feel of soft body stuff.
Each wheel is treated independently, and they are simply tied together with constraints, or rather damped springs. I have two versions, this version which is basically a 3D rectangle with 6 constraints, and also a 3D box version which has 28 constraints. I actually prefer the feel of the rectangle, so I'm using it, and it uses less juice.
Because the track is relatively low poly (10/12 thousand just for the base road and mountains, probably 16 thousand or so when it's complete, with trackside objects, buildings, tunnels etc) - I'm using the normal geometry for collisions to save on RAM and download times. There's a pretty low number of polys per node, most of which are quickly culled anyway. I'm using a broadphase grid by the way, they are very, very efficient with minimal overhead.
What kind of poly counts are the average tracks on other low power platforms, such as DS/mobile?
Oh and in regards to level design, I made this track with line/sweep, pretty easy to get the basis of a track formed. I then adjusted the altitude variation of the track with the line vertices after sweeping it.
I haven't made my mind up yet whether to use a variable or normalized spline. What do you think?
In some ways a variable one is better, because the corners should have more polys than straightaways. With a normalized spline of the same polycount, the corners are significantly lower poly, noticeably less smooth/round.
However, a normalized spline has the big advantage of being easier to UV, with completely uniform poly size.
The game is going to have at least 7 cars and 3 tracks. I'll upload videos as soon it's developed enough to warrant one
I'm surprised at how easy it is to write a custom exporter in Max Script. I guess that's partly just scripting languages for you. I don't like scripting languages because they can give you bad habits, but one can't help but like the ease of use.
Apart from the obvious perks of a custom exporter, the flexibility, and being to tailor it to your workflow/engine, the potential parse speed is another big perk.
I'm exporting objects as AS3. So the model data gets compiled into AVM bytecode. Needless to say, the data access speed of byte code is magnitudes faster than accessing strings or binary at runtime.
Check this demo out, it parses 109,000 polygons in half a second, which for AS3, is very good - http://rumblesushi.com/roku.html
You can press 3 to clear the engine and reload the objects, the parse speed gets updated.
Before I was just using OBJs, and in this demo a 20,000 polygon model takes significantly longer to parse than the 109,000 polys above - http://rumblesushi.com/trex.html
Incidentally my engine is faster than ever now. Basically as fast as it gets in AS3. There's some things I could do to improve data access speed further, that might net an extra frame a second, but that's about it.
It's a script to make baking a lot easier in 3ds max. The problem with max is that you need to define too much unnecessary settings before you can render something out that might have the result you are after.
With this tool: with one click you can render out any map (1 or more objects) you want going from basic maps (normal, diffuse, shadow, uv, etc.) to more complex maps:
AO Lighttrace, Gradient Map, Material ID masks, vertex color, animated textures, selection masks ... Place it directly into your clipboard to paste and use it in photoshop.
Also something useful for real-time fanatics I implemented the Xoliul shader to this tool, you can preview a baked normal map in to a real time shader to check if your bake had any flaws. (same for any other map)
It has been a great time saver for my texturing process.
And I hope it can help you guys out
Any ideas that I could implement are more than welcome!
Replies
I'm not saving any max files with this tool though, just saving out jpgs now, so u can see whats in a max file when merging without having to open it and search through it manually and unhide layers/ect.
Sockets...I was too stupid for that
But with named pipes I got it to work. So now we can launch python scripts with UI and make them talk to max and vice versa.
oooooooh
I just want to try and get better camera angles for the pieces if I can, which I think all I need to do is learn/figure out how to set each Objects Local Pivot's Y to Straight up (Z) , and use this look at controller setup to look at the perspective camera.
I also would like to get a progress bar working right, like the green install bar, that moves along, but I'm not sure I can do it properly with my setup.
anyways...
I'm thinking I should have my tools updated within a couple days or less. Maybe even tomorrow.. we shall see..
NEW:
- Added the Merge Geometry Preview, which is seen just above the last post. I have a video demonstrating it on the site as well.
- UV Vert to Mesh Vert - Converts a UV Vert Selection to a Mesh Selection. It will take the UV Vert selection, collapse the stack and have the verts selected for you.
I've also Fixed some random issues and such. You can see the bug list on scripts page as well.
http://www.matthewlichy.com/Scripts.html
Now we have much less of a code base to maintain! Most of our new plugins will have the majority of their code in Python, with the option to easily port them to Maya. This is especially useful for scripts which are theoretically app independent (e.g. file management, naming conventions, etc, etc)
Changes inside the python code are very very few to adapt a program to work with max or maya. All you need to do is use an if statement and then either write maya python/mel commands or dispatch your commands to max.
A standard header and footer has to be included into your python code which calls some commands to set up everything - there's usually nothing to change here for the TA when writing a script.
Communication is 2 way - trigger max functions from Python or trigger Python functions from Max.
Such programs run directly inside Maya and via max we use named pipes for inter process communication. Named pipes functionality can also be used from within Maya, allowing us to code a stand alone programs in C# or in a certain Python version where we have certain modules which we do not have in this Maya version.
Also we can write apps which talk to different (3D) apps at the same time. i.e. we could write a connector app translating stuff on the fly from Maya to Max (e.g. create a box, it creates one as well in Maya).
Per default one can use Qt, pyODBC and ctypes in such python scripts and expect them to run on all supported apps. Was quite some work getting all those modules together for x86 and x64.
so yeah...lots of work. But it paid off
...hiring a tech artist for Rockstar North.
http://www.polycount.com/forum/showthread.php?p=1228413#post1228413
watch this space! (or, maybe its own thread cos its a bit quiet in here)
Web Player
So I've been looking that the Qt UI minimizes when the 3D app minimizes, that it stays on top of the 3D app while you work with it, etc. works pretty nice
@Kwramm - Are you running a C++/C# windows form or whatever with Max? I want to learn how to do that sort of thing.
There are utility python functions which allow you to easily code apps which run either natively in Maya or talk via named pipes to max. This is especially nice for GUI frontends or database connectivity or P4 stuff - code once, use on many platforms.
However, lets say you need python modules with are not available for your maya version (often the case with x64), then you can also use named pipes, because we implemented a named pipes client in python for maya too.
e.g. you have a super image manipulation module, but it's only available for python 2.6 x86 and you're running Maya 2009 x64.
You could probably use sockets as well instead of named pipes, but I ran into problems with that....maybe I was just not clever enough to figure it out.
Right now we're working on cosmetics. since the python app is, when not directly launched from maya, a seperate process, it doesn't minimize with the app that launched it, it's ALWAYS in the foreground (should be in the background when the launching app (e.g. e3ds max) is inactive, should be in the foreground when it's active), etc.
http://keenleveldesign.com/pimp/gpgpu/raycasting01/WebPlayer.html
This example uses gpu raycasts to test visibility of the surface to an area light, the textures on the left are the scene triangle lists uses for raycasting.
Started looking into C# in 3DS Max. Using his .dll I was able to make my own .dll in C# in VS 2010, and get a form to appear on Load in Max, as well as print to the listener through C# and execute an existing function of mine written/loaded in MXS. Very cool stuff
Maybe you could add a bevel to the exposed block corners to make everything look a little smoother... but I'm sure others would prefer the crisp, cube-y look. Since Unity can handle more geometry than Java, though, it might be nice.
Vrav, I dont want to up the triangle count anymore. It has to rebuild at least 1 8x8x8 block cell every time someone modifies the terrain. Plus when I do stuff like baked indirect lighting and crumbling it will have to update them even more.
[ame]
This is looking really nice, have you thought about "simulating" life-support? to have close in controlled spaces of air vs the outside vacuum.
Ahah, my first thought after seeing the last video
And the best part about those gasses (for the most part) is that you cannot see them, so the clients don't need to know every block there's air on, they just need to know that they're suffocating.
any calculations can be done completely server-side
Keg, I plan on sort of doing a blured direct sky light coming from the up vector. So I would first caclulate what voxels can see directly up infinitely. Then in another pass I see what voxels that are in darkness are next to a voxel in light and then transmit some light from the lit voxel, then keep doing that for about 8 passes.
It sounds like a lot of processing, which it is, but after the first initial terrain generation only cells under the modified cell and their neighbors need to be updated, plus once the direct light at the position of the modified block hits a block, cells under that block dont have to be updated. It would have to be updated over multiple frames though, which is ok, and could be done server side. I think this is how its done in Minecraft.
A kinect plugin for Unity3d:
http://forum.unity3d.com/threads/67982-Kinect-plugin
unity test video:
[ame]
I think thats really cool, maybe I should start working on a 3d texture grabbing tool
he is one step further with his kinect hack
I just select a bunch of objects in max and based on their name it groups them into different groups with a name preview. There is also a heap delay because I noticed that buggy max crashes sometimes because some of the exporters is hanging or taking longer and not responding back to MXS.
anyway nice single button solution for updating models in Unity
someone needs to make a stereoscopic driver for using two Kinects at the same time.
its been done!
[ame]
WebPlayer
[ame]
Here are a couple of screenshots. Please ignore the crappy UVs and horrible road texture, this is just a test to see the design of the track and test the car handling etc. The car is going to be reworked too, as I made it without blueprints, and also forgot mirrors.
This is a full res shot, the next ones are half res.
Because it's an arcade style racer, I'm purposefully not referencing real car physics. I'm simply making up the physics and handling, and tweaking it till it feels right.
As you can see from the screenshots, I'm actually using soft body dynamics rather than solid body dynamics. Mainly because it's something I have more experience with, and I quite like the feel of soft body stuff.
Each wheel is treated independently, and they are simply tied together with constraints, or rather damped springs. I have two versions, this version which is basically a 3D rectangle with 6 constraints, and also a 3D box version which has 28 constraints. I actually prefer the feel of the rectangle, so I'm using it, and it uses less juice.
Because the track is relatively low poly (10/12 thousand just for the base road and mountains, probably 16 thousand or so when it's complete, with trackside objects, buildings, tunnels etc) - I'm using the normal geometry for collisions to save on RAM and download times. There's a pretty low number of polys per node, most of which are quickly culled anyway. I'm using a broadphase grid by the way, they are very, very efficient with minimal overhead.
What kind of poly counts are the average tracks on other low power platforms, such as DS/mobile?
Oh and in regards to level design, I made this track with line/sweep, pretty easy to get the basis of a track formed. I then adjusted the altitude variation of the track with the line vertices after sweeping it.
I haven't made my mind up yet whether to use a variable or normalized spline. What do you think?
In some ways a variable one is better, because the corners should have more polys than straightaways. With a normalized spline of the same polycount, the corners are significantly lower poly, noticeably less smooth/round.
However, a normalized spline has the big advantage of being easier to UV, with completely uniform poly size.
The game is going to have at least 7 cars and 3 tracks. I'll upload videos as soon it's developed enough to warrant one
Cheers,
RumbleSushi
Apart from the obvious perks of a custom exporter, the flexibility, and being to tailor it to your workflow/engine, the potential parse speed is another big perk.
I'm exporting objects as AS3. So the model data gets compiled into AVM bytecode. Needless to say, the data access speed of byte code is magnitudes faster than accessing strings or binary at runtime.
Check this demo out, it parses 109,000 polygons in half a second, which for AS3, is very good - http://rumblesushi.com/roku.html
You can press 3 to clear the engine and reload the objects, the parse speed gets updated.
Before I was just using OBJs, and in this demo a 20,000 polygon model takes significantly longer to parse than the 109,000 polys above - http://rumblesushi.com/trex.html
Incidentally my engine is faster than ever now. Basically as fast as it gets in AS3. There's some things I could do to improve data access speed further, that might net an extra frame a second, but that's about it.
Working on maxscript tool ToTex. (Render To Texture), already working on it for a few months.
http://sven.fraeysweb.be/tools/index.php?page=totex
It's a script to make baking a lot easier in 3ds max. The problem with max is that you need to define too much unnecessary settings before you can render something out that might have the result you are after.
With this tool: with one click you can render out any map (1 or more objects) you want going from basic maps (normal, diffuse, shadow, uv, etc.) to more complex maps:
AO Lighttrace, Gradient Map, Material ID masks, vertex color, animated textures, selection masks ... Place it directly into your clipboard to paste and use it in photoshop.
Also something useful for real-time fanatics
It has been a great time saver for my texturing process.
And I hope it can help you guys out
Any ideas that I could implement are more than welcome!
thaanks