Topic: Google Code Shutting Down

Google has announced today they're shutting down Google Code.[1]

So, maratis repository on google code should be migrate to github?

more on: http://google-opensource.blogspot.com/2 … -code.html

[1] http://www.phoronix.com/scan.php?page=n … tting-Down

Re: Google Code Shutting Down

Yes, I received a notification,
github is the right move yes : )

Re: Google Code Shutting Down

Hi Anael, any news regarding github migration?

I know, there is already free AAA engine right now, and maybe more on later, and there is plenty of promising new engine like godot engine, openfl, etc with their near complete feature for production and easiness to use. So do you have any plan or a state of this engine?
Maybe if you have a roadmap or so, you can share with us, so if there is someone who like to contribute they can do the milestone.

Re: Google Code Shutting Down

Hi jurgel,

I'm doing some cleaning in the code base right now, mainly to separate the low level code into a small C library, it won't affect the c++ code compatibility but I'd like to finish that before sending it to github.

I'm also including some other image processing code I have not shared yet, like additional ray-tracing code, some basic software rasterization, image filters etc. I'm using C here to make some of this code also usable in OpenCL or Cuda.

I just saw you did some good work on your github page, we can try to synchronize at some point, did you manage to compile the experimental branch with SDL2 instead of GLFW ?

Re: Google Code Shutting Down

Thanks for explanation, it is good to know that you have a plan for this engine.

I did successfully compile on Linux, Mac OSX (using hackintosh big_smile), Windows (MinGW GCC Compiler), Android and iOS.
It's working on Linux and Mac OSX, but crash on Windows and Android at glLinkProgram (some of your shader code in Standard Renderer), it did not crash if I comment "addFx" on shader1-8 code, but on Android version I only got a gray window (from glClear I think), I don't know it's because I didn't embed the assets, because I don't know how to do it big_smile, or the window didn't swap the buffer. It was become harder on iOS version, I managed to compile and installed on devices, but it crash immediately when I open the app.

By plan to implement OpenCL or Cuda, do you want to focus on desktop?
If yes, then it's good to keep GLFW than SDL2 I think.

I've tried deferred rendering and physically based shading, but I haven't process transparent object and light didn't have the shadow at the moment, it's hard to implement CSM for me. At some point maybe I try to implement global illumination using LPV, and it can use your OpenCL implementation for cell generation.

If you already push the code to github, I'll fork and make some pull request to merge the features.

Last edited by jurgel (2015-04-08 02:21:32)

Re: Google Code Shutting Down

That sounds good.

I guess SDL2 is more supported than GLFW, but GLFW is lighter, the best would be to keep both alternatives, if it's not too hard to maintain. We could just have multiple versions of MGUI_xxx.cpp.

I'm not sure about direct support for OpenCL or Cuda, but it would be nice if some of the high performance code could compile for both GPU and CPU (without having to rewrite it). I took some more interest in software rendering recently, I taught I'll share it.

OpenCL is on mobile already, and it's probably something that we will start to find more and more.

Like you said, there is a lot of AAA engines out there now, I'm thinking about different directions to experiment. Like software rendering (in CPU or GPU), image processing, simplicity.

A deffered renderer is interesting, tell me how it goes, I don't know much about real-time physically based shading.

Re: Google Code Shutting Down

I'd tried both of SDL2 and GLFW, but it's not a class so the function name conflict to each other.

Why do you have interest in software rendering? Currently many of them are used for fallback mode. It's different if you want non realtime rendering.

OpenCL can be used together with OpenGL also, they can share GPU memory through interoperability, I'd used it for post processing, although it can achieved by fragment shader, just for testing purpose.

Deferred rendering used to decoupling object(n) and light(m), so instead of we calculate n*m per frame, it can be n+m, hence we can use hundred of light in a scene, but still not all of them can have shadow, because shadow calculation is quite expensive. Deferred rendering also has advantageous like post processing such as blur, DOF, tone mapping, glow, flare, etc. But it has a problem for transparent object, so they need different process and if in standard rendering we could use many shader for each object, we can't do this in deferred rendering.

The process, first we draw all object color/albedo, normal, and depth (probably specular coef, IOR, roughness, etc we like) into separate texture using one frame buffer (usually named gbuffer), usually we can compact into different channel on one texture, like normal map using rgb channel, and roughness value into alpha channel.
Then we process this textures for every light into light buffer if we want some post process later or draw directly to screen.

Physically based shading is similar to standard shading such as lambertian model for diffuse shading and blinn-phong for specular shading, but physically based shading using more accurate rendering equation, it's approximately equal to what light actually does, so the result can be more natural. This can be achieved in fragment shader using additional material parameter like roughness and IOR, it's more expensive though. CMIIW smile

Re: Google Code Shutting Down

The SDL2 / GLFW versions can be handle with a define, in the code or in cmake.

My interest in software rendering is for multiple reasons, the first is to experiment different techniques and general image processing (not necessarily real-time), second is that we are entering a phase where GPUs are general purpose, so it opens a lot of possibilities.

In the indie scene, games are often trying to reproduce pixelized images on modern ultra-powerful GPUs. In this low resolution it is already possible to use software rendering to do different things, like hybrid rendering, ray-casting, (selective) ray-tracing, non-realistic rendering...

Voxatron does that in CPU, targeting old computers : http://www.lexaloffle.com/voxatron.php

Of course it's useless to reproduce very effective hardware techniques like shader based rasterization.

Re: Google Code Shutting Down

Did you mean voxel based rendering? It's cool if we could create voxel based game engine, but I don't know anything about it yet. If you have a specific plan for voxel based rendering, just let me know.
We can't combine the current code and we have to start from scratch if we want to implement it, because it's different on every aspect though.

After a bit of googling it looks promising for the future, as it can perform real time ray tracing, but I concern about sparse voxel octree creation per frame if we want dynamic scene, and there isn't many resource out there for further implementation, so this is required much research.

This is interesting and can make Maratis unique from others I think.

Re: Google Code Shutting Down

Voxel based rendering could be done with the base code, as other things, not as a full-feature engine though, something for little games or educational purpose. Well that's just an idea.

In fact I did some test some months ago in Maratis standard renderer : https://code.google.com/p/maratis/sourc … nderer.cpp

It's commented, but if you look at MStandardRenderer::updateVisibility
there is some test code to draw the voxels of the scene in software. The idea is to compute a low-res occlusion culling map on the cpu to avoid the overhead of hardware occlusion culling. It's not complete yet, but it renders voxels from a mesh.

Re: Google Code Shutting Down

It's great if we can add voxel renderer in current engine, so user can choose FixedRenderer, StandardRenderer, VoxelRenderer, and maybe DeferredRenderer later.

I don't understand how your code works smile, I'll look some reference to implement voxel based renderer which is compatible to CPU rendering then.

Re: Google Code Shutting Down

What is sorta crazy is I was just thinking of a style I wanted to do that I called a 3D 8bit style. Found the keyword was "voxel"

Found this software:

https://voxel.codeplex.com

Last edited by Tutorial Doctor (2015-04-10 03:51:18)

Re: Google Code Shutting Down

Yes, it's in the wind like pure old school 2d, a voxel is just a 3d pixel, it means "volumetric pixel",
it often looks like cubes, but in fact it is more like a stack of bitmaps (the stack being the Z dimension),
and because it's packed and aligned, it can be traversed very fast, using ray-casting or ray tracing.

When parsed directly it can render as cubes (like minecraft) or smoothed cubes depending of the filtering,
but it can also be converted to triangles using "marching cubes" and create smooth surfaces.

voxels are also used to accelerate the parsing of a scene for raytracing, like a fixed size octree.

Re: Google Code Shutting Down

I published a first version of the tiny C code we were talking about :
https://github.com/anael-seghezzi/Marat … -C-library

Still need to link it completely with MCore to publish the rest.

Re: Google Code Shutting Down

Great, looks like an optimized code.
I still think to implement SSE function for matrix or vector math function though.
It won't be portable, but it will cut down the number of instruction.

Re: Google Code Shutting Down

Normally the compiler will use SSE instructions when the code is linear and simple to vectorize like the raytracing functions (I tried to use intrinsic on the ray-triangle code but there was no speedup compared to the compiler).

But in maratis mesh tools, it was a good speed-up : (see void blendMatrices)
https://code.google.com/p/maratis/sourc … hTools.cpp

Re: Google Code Shutting Down

Hmm, I don't know if the compiler could do auto compile to SSE instructions. What compiler flags should I use? Or it's on by default?

It's a great then big_smile
Nice info. Thanks.

Re: Google Code Shutting Down

On x64 platform it should be by default, because SSE is a part of x64 standard, you may need to use "-O3" flag though.

But on 32bit it's not, so you need to add a compiler flag, on gcc it's "-msse2" ("-O3" may be needed too like above).

"-ffast-math" flag can also improve it. But it's potentially unsafe.

Re: Google Code Shutting Down

Some update on github : https://github.com/anael-seghezzi/Marat … -C-library
And a first web experiment compiled to asm.js with emscripten : http://maratis3d.org/js/m_voronoi/m_voronoi.html

Re: Google Code Shutting Down

That's cool, even though I know nothing about voronoi big_smile
So, anything can be compiled with emscripten or there are some adjustment to make it work?

Re: Google Code Shutting Down

The adjustment is quite small, I'm surprised how simple it is.
First thing to check is the window/events system, but when using glfw or sdl there is no problem (sdl is better supported though), then the main loop need to be parsed a bit differently. There might be some modifications to do for file parsing but I didn't test it.

Re: Google Code Shutting Down

I published the current (experimental) code of Maratis 4 on github - linked to Maratis tiny C library - with the base code of the new editor :

https://github.com/anael-seghezzi/Marat … -C-library

Re: Google Code Shutting Down

Great, I will fork from your repository and make some pull request later.