Hi all
this time i'v some "bad" news.
last post i wrote about a project i'm about to expose, unfortunately this isn't going to happened.
i turns out that when "my friend" saw we have some real thing in our hands he smell the money, and that make him do what he did this week.
i wont get into details (numbers and stuff), but i feel i need to share what went wrong so if you will be in my position you know what to do.
i got to know this guy from a good friend of mine, so i trust my friend that this guy is ok.
from day one our working model based on free time only!
i gave him X percent for starting, and he began to work on some models, after working for a while, i rise it 1.5X and eventually he got 2X percent, even that the work he did stays the same, average of one model per week! (for the simple ones!, complex ones could get to one month)
2 weeks before exposing he told me that he wants more and told me to think very careful about what i'm going to say, so i though and even that there was no good reason to rise it up, i want him to be happy, so i give him another 25% of the 2X he got and told him i want him to sign on a contract i will arrange about everything we agreed on.
this week he told me that he doesn't want to continue, talking a little bit with him i realize that he wants 25%+, and he told me that i can't use his models in anyway... for the record, i can use them for non profit use, but i decided that i don't want to, i don't want him to have anything with my projects not now and not ever...
after checking out what he actually did in almost 2 years i saw its less than 50 models! including the simplest one (cans, bottles, barrels etc), so giving him 25% is giving him 0.5% per model!
so the bottom line of all this little story is:
don't trust anyone when doing this kind of thing, make a construct from day one, i did one and gave him but i didn't insist him to sign it, bad mistake.
i will be happy to hear what do you think, did i do the right thing? did i handled it correctly?
i always knew that money can blind wise peoples, but now i know that even the smell...
i will continue to update this blog, hopefully more recent...
cya
Wednesday, October 19, 2011
Thursday, October 6, 2011
Stay Tuned for the BLAST!
hi
recently i'm not updating this blog often, the reason is that me and my friend working very hard on a big project and i can't find time to post, every free minute i have i put in the project...
if you are curious, here are some Q/A:
* so... whats the big project you are working on?
well, basically it's a game.
* what kind of game?
that's will be published soon.
* what is so special about this game?
feeling! we work hard to make it feel real, in terms of look and feel...
* is it going to be a full game?
no, for now we will publish one level, to show what we can do.
* what engine are you using?
internal, for now i named it: OGE (oren game engine)
* why didn't you use cry-engine,unreal, unity,ogre, or any other free engines out there?
one word: freedom!
* can you tell about the engine a little?
yes, but this can be a very long answer, so here are few cool things we have:
soon i will post screenshots of the project, and talked about few nice things i'v added into.
* do you need people to join in?
yep, basically we need:
art guys - concept, models, textures, animations etc...
sound/music guys to do sound effects and music.
so if you know someone, feel free to contact me.
i'v you have questions you want to ask, feel free...
cya
recently i'm not updating this blog often, the reason is that me and my friend working very hard on a big project and i can't find time to post, every free minute i have i put in the project...
if you are curious, here are some Q/A:
* so... whats the big project you are working on?
well, basically it's a game.
* what kind of game?
that's will be published soon.
* what is so special about this game?
feeling! we work hard to make it feel real, in terms of look and feel...
* is it going to be a full game?
no, for now we will publish one level, to show what we can do.
* what engine are you using?
internal, for now i named it: OGE (oren game engine)
* why didn't you use cry-engine,unreal, unity,ogre, or any other free engines out there?
one word: freedom!
* can you tell about the engine a little?
yes, but this can be a very long answer, so here are few cool things we have:
- Editor - the engine is just loading and running levels, all logic and gameplay scripted or set by the editor (nothing is hard coded)
- Graphics - real-time GI, HDR, filmic tonemapping and filmic DOF , sun effects, flares unlimited lights and shadows! (every light cast shadow) and more...
- UI - script based dynamic UI system supporting any resolution.
soon i will post screenshots of the project, and talked about few nice things i'v added into.
* do you need people to join in?
yep, basically we need:
art guys - concept, models, textures, animations etc...
sound/music guys to do sound effects and music.
so if you know someone, feel free to contact me.
i'v you have questions you want to ask, feel free...
cya
Monday, August 15, 2011
Sun Lens Flare
hi
this time i added sun lens flare effect, if you don't know what i'm talking about, just read about it here
http://en.wikipedia.org/wiki/Lens_flare
or if you are lazy :) here is a picture shown this effect:
anyway, to create this effect, what you really need is few things:
1. couple of flare images
2. light position in 2d (screen space)
1. this is simple, just google on it, and you'll get some nice textures... (you can also use photoshop)
2. take you sun light position and project it into screen space, check z to make sure the light isn't behind the camera.
after you have this 2d pos, you need to create 2d direction vector pointed to the center of the screen, and place the flares from 1 in a different color/sizes along this vector.
that's it.
one thing to note is that flares do not disappear immediately when occluded, they basically stay visible and fade away very nice and smoothly (also when they become visible), thats because these flares created from a very bright light sources.
to achieve this kind of effect, what we really need is a way to count how much the light is occluded.
from this info we can compute a scale factor between [0..1] and scale the lens color so they fade in and out smoothy.
few options to use:
1. the simplest and naive way is to trace few rays from the light to camera eye and see how many of them passed and then compute scale factor from 0..1
pros: simple to implement.
cons: not accurate, can hurt performance.
2. texture masking, you render the scene from light point of view to small render target, lets say 16x16 (cleared to white), for every pixel passed you write black, at the end this texture will tell you how much the sun is occluded (the black pixels), to get the result from it, you can lock it out and count for the black/white pixels - not good idea, a better way is to render this texture into 1x1 render target (float point rt, and we will have to use 16x16 vertices for each pixel), we need to enable alpha blending to count the pixels. note that 1 in the 16x16 rt, could be counter for 256 times if all the texture is white (sun isn't occluded), but we need a value between 0..1 to scale the lens color with, so what we output from the ps, is the sampled pixel from the 16x16 rt scaled by 1.0/256.0 (16x16 = 256)
pros: better accuracy.
cons: not easy to implement, need hw float point rt, can hurt performace for big scenes.
3. use hardware occlusion query, just rendered some simple query mesh (quad,box,sphere) and count how many pixels passed, from this you can compute scale factor between 0..1
note that its a little tricky to use, you need a way to know the maximum pixels for the query mesh so you could compute the [0..1] scale factor, second, they can hurt your performance if isn't used right.
pros: very accurate, performance is very good if done right.
cons: need hw occlusion query support, can be tricky to do right.
here is a scren shot to show you the effect in action:
in my implementation i use option 3...
that's it for now, cya until next time ;)
Sunday, June 12, 2011
Sun Shafts / God Rays
hi
this time i talk about nice effect called: sun shafts/god rays/sun rays...
to save words explaining what it is, i found a nice picture that shows how this effects looks like in reality:
notice how the sun "enters" between the trees and block by others, this create the light shafts you see in the picture.
so how do we going to do this effect in real-time you ask?
well, very simple, good old demo scene effect called radial blur as post process effect will do the work (well, with a little help of some Gaussian blur)
so the main steps is:
1. compute light position in screen space (this is our sun light pos)
2. compute radial blur on our image, this is done by blurring the image using normalized pixel to light direction.
something like this:
blur_dir = (sun_pos_2d - pixel_pos) / NUM_SAMPLES
sum = 0
for i = 0 to NUM_SAMPLES do
{
sum += sample(image, uv)
uv += blur_dir
}
return sum / NUM_SAMPLES
this is just an example of the radial blur idea, keep in mind that in order to make the effect looks good you need to weight the samples to give you the best look that you are looking for.
3. combine both sun shafts result we got in 2, with our original image.
thats it.
here is some pictures to show the effect in action:
with sun shafts
if you follow exactly by the steps i wrote, you probably need a lot of samples to get nice results, so here is few tips to make the effect fast and smooth:
1. try to down sample your image and apply the sun shafts effect on it
2. blur the sun shafts result with your favorite blur (should be fast enough)
3. because it a post effect, the effect will apply the sun shafts on all the image resulting shafts from none sun light pixels, to overcome this, you should mask out all pixels that shouldn't be effected by the sun shafts effect, techniques to consider:
* stencil buffer
* depth buffer
whatever fits you engine...
that's it for now, if you have any question, feel free to ask...
cya until next time
this time i talk about nice effect called: sun shafts/god rays/sun rays...
to save words explaining what it is, i found a nice picture that shows how this effects looks like in reality:
so how do we going to do this effect in real-time you ask?
well, very simple, good old demo scene effect called radial blur as post process effect will do the work (well, with a little help of some Gaussian blur)
so the main steps is:
1. compute light position in screen space (this is our sun light pos)
2. compute radial blur on our image, this is done by blurring the image using normalized pixel to light direction.
something like this:
blur_dir = (sun_pos_2d - pixel_pos) / NUM_SAMPLES
sum = 0
for i = 0 to NUM_SAMPLES do
{
sum += sample(image, uv)
uv += blur_dir
}
return sum / NUM_SAMPLES
this is just an example of the radial blur idea, keep in mind that in order to make the effect looks good you need to weight the samples to give you the best look that you are looking for.
3. combine both sun shafts result we got in 2, with our original image.
thats it.
here is some pictures to show the effect in action:
with sun shaftsif you follow exactly by the steps i wrote, you probably need a lot of samples to get nice results, so here is few tips to make the effect fast and smooth:
1. try to down sample your image and apply the sun shafts effect on it
2. blur the sun shafts result with your favorite blur (should be fast enough)
3. because it a post effect, the effect will apply the sun shafts on all the image resulting shafts from none sun light pixels, to overcome this, you should mask out all pixels that shouldn't be effected by the sun shafts effect, techniques to consider:
* stencil buffer
* depth buffer
whatever fits you engine...
cya until next time
Tuesday, May 3, 2011
Bitwise Operators on Low End GPU's
hi
recently i was needed to perform bitwise operators on SM 3, but as you know, SM 3- doesn't support it (only DX10 SM 4.0 and up).
if you try to write this line: (hlsl SM 3 for example):
some_var & 2
you will get error message saying: Bitwise operations not supported on legacy targets.
the technique i present here can be used for few more things (lighting, shading etc), but here i will show how to do bitwise ops with it.
i support: &, |, ^ (AND,OR,XOR) - more complicated operators could be used but these are the base.
the trick is to use a texture to store the results of these operators, and then to sample this texture and get the result.
a code to compute this texture will look like this: (assuming 8 bit range for AND op)
for i=0 to 255
for j=0 to 255
texture[i][j] = i & j
to maximize storage, encode different operators on different channels.
here is a sample texture that encode AND,OR,XOR in different channels:
bitwise operators texture: AND,OR,XOR
recently i was needed to perform bitwise operators on SM 3, but as you know, SM 3- doesn't support it (only DX10 SM 4.0 and up).
if you try to write this line: (hlsl SM 3 for example):
some_var & 2
you will get error message saying: Bitwise operations not supported on legacy targets.
the technique i present here can be used for few more things (lighting, shading etc), but here i will show how to do bitwise ops with it.
i support: &, |, ^ (AND,OR,XOR) - more complicated operators could be used but these are the base.
the trick is to use a texture to store the results of these operators, and then to sample this texture and get the result.
a code to compute this texture will look like this: (assuming 8 bit range for AND op)
for i=0 to 255
for j=0 to 255
texture[i][j] = i & j
to maximize storage, encode different operators on different channels.
here is a sample texture that encode AND,OR,XOR in different channels:
bitwise operators texture: AND,OR,XORthe way you use this texture in your shader looks something like this: (hlsl style)
float AND(in float A, in float B)
{
tex2Dlod(BitwiseOpMap, float4(A, B,0,0)).r;
}
NOTE: make sure you use POINT sampling, you don't want to filter the results in the texture, you also don't need mipmaps...
thats it, i hope you find this post useful...
cya until next time ;)
float AND(in float A, in float B)
{
tex2Dlod(BitwiseOpMap, float4(A, B,0,0)).r;
}
NOTE: make sure you use POINT sampling, you don't want to filter the results in the texture, you also don't need mipmaps...
thats it, i hope you find this post useful...
cya until next time ;)
Sunday, May 1, 2011
Post Anti-Aliasing #2
hi
few months ago i'v read an article on intel research group called: Morphological Antialiasing.
this technique designed for cpu but with few tricks and hacks we can use it on gpu as well.
the algorithm consist of 3 main steps:
1. find discontinuities between pixels
2. identify predefined patterns
3. blend pixels in the neighborhood of the patterns in 2
1. simple edge detection on the image, using depth or color differences should do the work, keep in mind that you should encode edge type in you color channels so you could use it in 2, lets say red is horizontal edges, and g is vertical edges.
2. this is tricky, you basically need to identify few shapes: Z, U, L
see image below (grabbed from original intel article):

so based on the article, you only need to identify L shapes, as Z, U can be split into L shapes.
for more deep information please refer to the original article that can be found here:
http://visual-computing.intel-research.net/publications/publications.htm#Y2009
to identify L shapes there are few tricks, a simple one is to just follow the edges you mark in 1 and see if you get a match (few loops for each side: left/right/top/bottom and of course branching), if so you compute blend weights for these and continue to the next edges.
at the end, you end up with blend weights texture so you could blend the pixel to get the final image, you can use a the trick described in gpu pro 2, they encode the final weights in textures and sample it.
btw: if you have ATI HD 6850+ you have built in support for that, so no need to worry, for consoles you may want to worry a little ;)
this technique isn't simple to implement as a first shot, i tried few algorithms and techniques before i got this thing working.
after seeing the demo from gpu pro 2, i'v got to say i was impressed by the speed of their implementation so i put some tricks into mine as well to get the missing cycles :)
optimization tip: when doing edge detection pass, use the stencil buffer to mark these pixels, then in the next step, use the stencil apply your "massive" shapes/blend weights shader only on edges pixels, this way you won't waste power on irrelevant pixels
here is a few screenshots of the main steps and result:
as you can see, this technique have very good result.
extra: few other techniques you should check:
* GPAA - show it at humus
* FXAA - nvidia sdk 11 (looks pretty good)
cya until next time...
few months ago i'v read an article on intel research group called: Morphological Antialiasing.
this technique designed for cpu but with few tricks and hacks we can use it on gpu as well.
the algorithm consist of 3 main steps:
1. find discontinuities between pixels
2. identify predefined patterns
3. blend pixels in the neighborhood of the patterns in 2
1. simple edge detection on the image, using depth or color differences should do the work, keep in mind that you should encode edge type in you color channels so you could use it in 2, lets say red is horizontal edges, and g is vertical edges.
2. this is tricky, you basically need to identify few shapes: Z, U, L
see image below (grabbed from original intel article):

so based on the article, you only need to identify L shapes, as Z, U can be split into L shapes.
for more deep information please refer to the original article that can be found here:
http://visual-computing.intel-research.net/publications/publications.htm#Y2009
to identify L shapes there are few tricks, a simple one is to just follow the edges you mark in 1 and see if you get a match (few loops for each side: left/right/top/bottom and of course branching), if so you compute blend weights for these and continue to the next edges.
at the end, you end up with blend weights texture so you could blend the pixel to get the final image, you can use a the trick described in gpu pro 2, they encode the final weights in textures and sample it.
btw: if you have ATI HD 6850+ you have built in support for that, so no need to worry, for consoles you may want to worry a little ;)
this technique isn't simple to implement as a first shot, i tried few algorithms and techniques before i got this thing working.
after seeing the demo from gpu pro 2, i'v got to say i was impressed by the speed of their implementation so i put some tricks into mine as well to get the missing cycles :)
optimization tip: when doing edge detection pass, use the stencil buffer to mark these pixels, then in the next step, use the stencil apply your "massive" shapes/blend weights shader only on edges pixels, this way you won't waste power on irrelevant pixels
here is a few screenshots of the main steps and result:
as you can see, this technique have very good result.
extra: few other techniques you should check:
* GPAA - show it at humus
* FXAA - nvidia sdk 11 (looks pretty good)
cya until next time...
Sunday, March 20, 2011
Adding Vegetation
hi
one of the thing i always wanted to add is vegetation, tree, weeds, grass etc...
in a nutshell, to support all kind of vegetation you need to have few things:
1. some app to generate the content, plant model, textures etc.
2. engine supporting geometry instancing.
3. extra (depends of scene size), engine supporting model level of detail (LOD)
4. extra (depends of scene size), engine supporting good outdoor culling.
1. this is very critical, having great app for generating plants is a must, if the model and textures isn't quality enough, the best code won't do much... i checked some apps, and i want to tell you that if you have some $, speedtree is the way to go, checked it, love it...
2. if you are going to render plants, you won't render one tree with 1x1 meter of grass, you probably want to spread it all over a 1x1 km terrain, so you are going to render hundreds of the same plant with different properties or such, so you don't want to kill your gpu with 20000 draw calls... unless real time performance isn't an issue for you.
for me performance is critical so i'v implemented instancing support for each plant type.
3. if your scene is large enough you need to consider LOD support, there is not need to render full plant geometry from certain distance, you probably won't notice if its real geometry or simple billboard, but your gpu will, so consider replacing you full model with low model or even quad when distance to eye pos is large enough.
i added auto lod support in the engine and use it also for plants (maybe i will post on it next time)
4. if your scene is large enough and you have massive amount of plants, so you already know that its a good idea to cull your data.
anther thing, because we are using instancing on the same model again and again, its a better idea to break symmetry when rendering the plants.
you can place them with different rotation and apply random motion for each plant (in shader).
here is a screenshot of a test scene:
cya until next time...
one of the thing i always wanted to add is vegetation, tree, weeds, grass etc...
in a nutshell, to support all kind of vegetation you need to have few things:
1. some app to generate the content, plant model, textures etc.
2. engine supporting geometry instancing.
3. extra (depends of scene size), engine supporting model level of detail (LOD)
4. extra (depends of scene size), engine supporting good outdoor culling.
1. this is very critical, having great app for generating plants is a must, if the model and textures isn't quality enough, the best code won't do much... i checked some apps, and i want to tell you that if you have some $, speedtree is the way to go, checked it, love it...
2. if you are going to render plants, you won't render one tree with 1x1 meter of grass, you probably want to spread it all over a 1x1 km terrain, so you are going to render hundreds of the same plant with different properties or such, so you don't want to kill your gpu with 20000 draw calls... unless real time performance isn't an issue for you.
for me performance is critical so i'v implemented instancing support for each plant type.
3. if your scene is large enough you need to consider LOD support, there is not need to render full plant geometry from certain distance, you probably won't notice if its real geometry or simple billboard, but your gpu will, so consider replacing you full model with low model or even quad when distance to eye pos is large enough.
i added auto lod support in the engine and use it also for plants (maybe i will post on it next time)
4. if your scene is large enough and you have massive amount of plants, so you already know that its a good idea to cull your data.
anther thing, because we are using instancing on the same model again and again, its a better idea to break symmetry when rendering the plants.
you can place them with different rotation and apply random motion for each plant (in shader).
here is a screenshot of a test scene:
cya until next time...
Subscribe to:
Posts (Atom)










