• entries
  • comments
  • views

Entries in this blog


This is basically a duplicate of what I've wrote on my recently created blog (https://ongamex.github.io/maya/mel/2017-09-08-Maya2DAnim/).

In order to do 2D animation in Maya, you have to import the images, assign them to material, then assign those materials to planes, and those planes must be properly sized with correct UVs, in order not to stretch the images. Doing this by hand is extremely annoying, so I wrote this script

// <?php This is actually mel script, I'm just using the syntax highlight for php ^_^

// This scripts creates a planes and assignes to them materails
// that use 2D textures for their colors. Useful quickly importing 2D 
// things for animation.

proc string obtainFilename(string $path)
  $filepart = match( "[^/\\]*$", $path );
  string $buffer[];
  tokenize $filepart "." $buffer;

  return $buffer[0];

proc textureTo2DPlane(string $textureFileName)
	$filename = obtainFilename($textureFileName);
	// Create the texture and a 2D placement for it.
	$textureFile = `shadingNode -asTexture -isColorManaged file -name ("file_"+$filename)`;
	$texturePlacement2D = `shadingNode -asUtility place2dTexture`;
	connectAttr -f ($texturePlacement2D+".coverage") ($textureFile+".coverage");

	setAttr -type "string" ($textureFile+".fileTextureName") $textureFileName;
	// Create the material and attach the file as an input color.
	$material = `shadingNode -asShader lambert -name ("mtl_" + $filename)`;
	connectAttr -f ($textureFile+".outColor") ($material+".color");
	connectAttr -f ($textureFile+".outTransparency") ($material+".transparency");
	// Obtain the size of the texture.
	float $size[2] = `getAttr ($textureFile+".outSize")`;
	// " -axis 0 0 1" will make the "plane" in XY plane, facing Z.
	// "sx" and "sy" control the amount of segments in each plane.
	$mesh = `polyPlane -w ($size[0]) -h ($size[1]) -sx 1 -sy 1 -axis 0 0 1 -name ($filename)`;
	// Now apply the newly created material.
	// TODO: Check if we could do this without selecting.
	// TODO: Should I create a default shading group?
	select $mesh;
	hyperShade -assign ($material);

proc promptForFiles()
	string $filenames[] = `fileDialog2 -fileMode 4 -caption "Import Image"`;
	for($i = 0; $i < size($filenames); $i++)


You can execute it directly in the "script editor", or create a shelf button that executes it.


I hope you find it useful ^_^


Finally I've got a big chunk of time to program my personal projects.
The last several months I was spending my mental state at work( we finally released Phoenix FD 3.0

) and then at home trying (or wasting my time) to come up with a grand plan for a level editor that does everything: C++ code reloading, undo/redo, serialization, edit while play, and is implemented as simple as possible. This basically burned me out and I gave that plan up for a few months.

I had 10 vacation days left for this year (this is how it works in my country, every year we have ~20 paid vacation days), so i took them and started coding my level editor with refreshed mind.
So here is a screen shot of what I manged to code for a few days.

So basically this is a "Skeleton" of a 3d "editor:, meaning that it is general purpose and can be reused for different context. The architecture consists of:

- "EditorInstance" is the structure that holds the whole data for the scene. Everything from nodes, per node type properties, selected nodes ect.
- "EditorView" is the stricture that manages displaying and accepting input for editing the scene via a "viewport". This does not include the GUI, it is only the viewport and input that is related to it (like clicking inside of it to modify the scene).
- A GUI that just reads the data that is stored in "EditorInstance" and displays it (in my case the Parameter editor, the Outline, the buttons, ect.)

I KNOW that call the "Scene editor" and editor is pretty dumb but this is how it is named in the code. I will changed in the future, but I cannot come up with anything, so any ideas are welcome.

My initial plan for level editing was to use Maya and hotlink it with the game in order to reload levels (Maya has a sockets API), but I backed up form the idea, as I do not want to get tied to any version of a 3rd party software, as there are many many restrictions (the C++ compiler version for example, Maya and 3ds Max are usually lagging behind the MSVC C++ runtime versions), and I'm highly interested in that subject.

So the way that I plan to use that editor is to basically to import the the edited scene in the game, load what is needed and play it.

I really wanted to have "one structure" per object type that is used for both game and editing levels in order to reduce to code complexity and make everything to just work,
but as I think out it "what you edit is not what you play", while editing there is a lot of helper data that is needed just for editing and I didn't wanted to tray my game with such thing.
I gave up on the "edit while play" for the same reason.

the editor currently supports:

- Creating new nodes
- Creating parameters/attributes for the nodes on the fly
- Duplicate and Delete nodes.
- Custom and auto generated UI for the nodes
- Tool to manipulate the scene. For example there is tool to move/rotate/scale nodes, control the camera. So in theory in the future making a tool for terrain editing shouldn't be that hard(not that I've planned to add).
- Multiple viewports(not tested, but should work).

The things that I'm going to focus next few days (if I have time as a few family holidays are coming) are:
- Serialization (this should be pretty easy)
- Undo/Redo. I do not plan to use the command pattern. I will try to serialize the scene to something on every significant change. I think it wont be that slow and I will be less code and more stable.
- Animated parameters, not sure how needed that is, it is there, but not tested, and there is no interface for it.

Additionally Im trying to avoid callbacks as much as possible. Maya for example is full of callbacks and implementing a little bit more complex feature gets really hard sometimes as there are a ton of callbacks and a ton of context switches. Instead I use something called "dirty index" For example.

In Maya when an attribute was changed you can get(if you subscribe to) a callback that say "this attribute was changed. In my editor Every attribute (well no every currently one per node) has an "dirty index", so when I change the value of an attribute, I increment the "dirtyIndex" for that value, so anyone who is interested in that attribute can check if the dirty value was changed by comparing it to internally stored one from the last update. This currently works really well and save me a lot of typing and loosing my mind on callbacks and call orders.

Wow that was kind of long by my standard. I'm happy to hear any suggestions, experience with such things (as there isn't much on that subject on the web), and I'm open to questions ^_^


Currently as a side project I'm writing a small rendering engine.

- The engine(named SGE) has two underlying implementations: Direct3D11 and OpenGL (currently 'a state of art' but in my mind targeting GLES3).
- In addition I have wrote a minimal shading language that I call "XShader" that can be translated to both HLSL and GLSL. The project is done with flex/bison. It's still not usable by anyone besides me but I plan to spend time on it in the future.

- I really did a few interesting stuff in that rendering part, but I want to write a separate journal about this.
- The "engine" currently runs under Windows and Linux, I haven't tried any other platforms but I think there will be almost no problems porting it.

- To store 3D models I use a "json header" followed by a big binary blob. The idea is to be able to make "quick" edits to a file if needed. The file format support the usual stuff: node animation, skinning, custom animated channels, node hierarchies, materials etc...

- Additionally I'm writing a minimal editor, meaning that I'm not trying to replicate Unity nor Unreal (or any other engine). I'm writing only the backbone that I think is needed in almost every game.Eventually when I know what game I wanna make I will extend/rewrite the editor to fit my needs.

The 3rd party libraries that I use are:
fcpp - a C++ style processor for XShader
Assimp - to covert the models to my internal format
ImGui - for the editor UI.

I really wanted to have few fancy images to show, but I haven't written any cool shaders or anything the only thing I got is this quick gif:


XShader - there were almost no updates since my last journal( https://www.gamedev.net/blog/1921/entry-2261196-common-shading-language/ ) but here is the currently "playground" public repo - https://github.com/ongamex/XShader When I have time I'm going to rewrite it.

For the future I really want to start making a game(I have troubles finding a inspiring game idea), eventually spend some serious time in the XShader language, and implement a minimal ray-tracing for baked effects.
Additionally I want to learn how to draw/model but I really don't know how to start.

The saga started here : https://www.gamedev.net/topic/668484-hlsl-and-glsl-wraping-again/#entry5234746

Basically I want a clean way to be able to use one shader program with multiple rendering APIs. As described in the linked topic above, my current solution to this problem is to match and modify specific tokens in my intermediate "language" in order to generate the final HLSL/GLSL code. This may sound good ?n paper, but as you can see (in the topic above) the shader code is bloated, ugly and highly unextendable (this is why I'm trying to solve this issue with a different approach).

After asking the public, I've decided to give the language writing a try (thanks to L. Spiro and a colleague of mine - G. Totev).

The idea is to write a language that could be translated to HLSL/GLSL/(something else). I was really scared of that task because... well, it is about writing a compiler and certainly I don't know (and still don't) how to write one.

Thankfully, there is a pair of tools - Flex and Bison (their ancestors are lex and yacc). These tools are used to describe the language.
Flex is used for finding (matching) keywords, strings, literals, identifiers, and Bison is used for matching those tokens in expressions (in other words describing the grammar of the language by using context free grammars). The Output of these tools is a set of C/C++ function(s) that knows how to parse your language. But more on C/C++ integration with Flex/Bison later (or maybe in another Journal).

After grinding a lot I found out that this isn't that hard of a task for my humble needs. The big problem was finding good resources on the topic. After hours of researching I found these :
(a quick hint: add yacc to your search query in order to increase the chance for correct results).

I'm currently in the process of developing that language. This is still not a complete solution, but the hard work is almost done.

The language can :
- Deduce the type of an expression ( for example the languages knows that matrix * vector in HLSL should be mul(matrix, vector) )
- Variable shadowing.
- Is able to produce some HLSL/GLSL (the shading stage specifics aren't yet supported, but it's just a matter of time. Currently there are input/output varyings, global uniforms, vertex attributes).

- Error checking is done only if the code generation depends on it. I want the code simple, why I want that is described below.

The code can be found here : https://github.com/ongamex/playground/tree/master/lang KEEP IN MIND THAT IT IS A PLAYGROUND REPOSITORY, but you can look at it if you're curious.

So what is the final goal?

The ultimate goal is to provide the base functionality (not a complete solution), that is easily extendable by others.
There are similar projects that either dead or their code is too complicated which basically means that insane amount of time is needed to create a modification. Currently the project doesn't meet this requirement (but the code is still very simple). In order to achieve that I must find the best architecture for the code and write (or find) a good tutorial about Bison.

And finally a quick demo of the language :// KEEP IN MIND THAT THIS IS NOT A REAL SHADER :)// GLSL like declarations with nice flavor of HLSL's semantics.attribute vec3f a_pos : POSITION;uniform Texture2D diffuseTex;out vec2f uv; //output varyingin mat4f world; // input varyingvoid main() { mat4f m; vec4f v = vec4f(5); int x = lerp(0.3, 0.0, 1.0); uv = 2; // the language still doesn't care about types, but... // HERE it does // the compiler knows that we are multiplying a matrix by a ?????. // And outputs the correct result m * lerp(0.3, 5.0, 10.0) * vec4f(0.0); m * mix(0.3, vec4f(0), vec4f(1.0)) // if-else branching works fine... if(x>0) v = -(world * -v.xxxy * +(getm() * v)); // member access and swizzles. else if(x<0) x = 10; vertex_output = v; }mat4f getm() { return; } // the language doesn't care what you're are actually returning, but you can get that error from the hlsl/glsl compiler.
And so far the output HLSL(I will skip the GLSL) looks like this(with a bit of shuffling) :uniform Texture2D diffuseTex;uniform sampler diffuseTex_sgeSS;float4x4 getm() { return;}struct SGE_SHADER_RESULT { float2 uv : uv; float3 vertex_output : SV_Position;};SGE_SHADER_RESULT main(float3 a_pos : POSITION, float4x4 world : world) { SGE_SHADER_RESULT sge_shader_result; float4x4 m; float4 v=float4(5); int x=lerp(0.30, 0.0, 1.0); sge_shader_result.uv = 2; if(x > 0)v = -(mul(world, -v.xxxy) * (mul(getm(), v))); else if(x < 0)x = 10; sge_shader_result.vertex_output = v; mul(m * lerp(0.30, 5.0, 10.0), float4(0.0)); mul(m, lerp(0.30, float4(0), float4(1.0))); return sge_shader_result;}
I will post more updates about the language here or In a new journal. Feel free to ask me anything, report an error, and give any type of feedback!