Something Tasty...

[GaborD]

Would love to see a game with this style.

[therevills]

Looking good Adam! 

[col]

This editor is looking real cool.
I like the visual style you have going on there with the 3D models.

[iWasAdam]

I've been working with the final render code (where the occlusion and line rendering takes place. I'm toying with the basic concept of paint - surface finish and faux ssao.

Here's my take on them with settings turned right up. these will be controllable in the final version. Note these are flat shaded - no textures, no bumps, nothing added!
it's sort of messy, but has a definite style to it I think?

[iWasAdam]

ok, so what I've done is added a new tab: Render. this is where all the final render stuff lives. currently It I've added line:


And as you can see the lines go from black to white, have different triggers, widths and alpha controls. Next up will be paint and then ssao, and color controls. This chould give loads of options for the final look of any output

[iWasAdam]

from clean to dirty 


The new paint fx and occlusion are very configurable

[Derron]

Somehow the outlines of the "pyramid" make it look "blurry" on top (until you look long enough at it and focus on the lines). Might be because the grey is too bright for the background.
I would also suggest to add the dirt "spray effect" on a separate texture layer. Then blur the layer (gaussian or so). Afterwards add some spray dust particles again (on top).
Else you end up having kind of sharp and too crisp dust/dirt corners/sides next to smooth shading gradients.

Also remember: dust and dirt are not just black ;-)


bye
Ron

[iWasAdam]

it's just a quick demo - nothing solid

I'm gonna take some time and see if I can untangle Marks implementation of 3d. Once I've found the key I will transfer the 3d render stuff over to the actual GPU which will speed things up and mean I wont need to do sorting yay!!!!

[iWasAdam]

ok, found out how to remove mojo3d from a module and be able to dissect it as standard code.

Here's my observations so far...
Current download version is V1.1.18 and the base I am using is V1.1.06 (this is what MX2 is built from)
Quick test of mojo3d demos. and found that there is something 'odd' going on with the later release. same basic file/demo gives the following:
MX2: loads, pause for a second, demo runs 60fps stable
monkey2 latest version: loads, waits for a loooooong time (thought it had crashed!), demo then runs at 30-39fps!

looking into the code (for some ideas about instancing) I found out that this is not being used, rather build a buffer and send it as a single entity. Sprites are done the same - interesting

If anyone is curious as to why I am delving into Marks code. simple answer "shadows" - and no sorting

[iWasAdam]

OK. Here's my first attempt:


What you are seeing is four colored cubes (red/green/blue/red). These are then going into the 3d pipeline with deferred rendering showing the buffers in  quarter stripes:
first is the final version with shadows. second is pure color, third Normals and finally the depth buffer.

Everythig is slowly being tested and transferred over from the 2d render into the 3d render systems. Interesting times

[Qube]

You have a great skill of learning things fast - Is there like a class we can take or something?

[Derron]

So after you tried to do everything in 2D you now use the 3d functionality doing much of the stuff for you? You could have done that right at the beginning (and learn your texturing stuff right in 3D) ?


bye
Ron

[iWasAdam]

No classes i'm afraid - possible rewire of brain a bit?

@Derron Simple answer is no. Longer answer is:
- I needed to rewrite the entire 3d editor code from 32 to 64 bit and from Blitz to MX2.
- This meant looking at the original 3d code and finding the best way to approach it
- This also means having a way to draw and edit in 2d viewports (top, side, etc). So to edit a 3d model you need direct access to the complete 3d data, and understand how it operates. Loads of really nasty dirty stuff that anyone using a nice 3d editor wont have to think about. But I'm writing the editor so I NEED to both understand it and how it all fits together. That's the easy bit.
- next is the software render, again not trivial but not too difficult at a basic level. Where things get nasty is stuff to do with pixel rendering vs triangle rendering. if you are doing at the pixel level then you can implement thing like depth buffers and use them to auto-sort/clip pixels for you. the trade off os speed. Hence using the base shader access fro 2d. But... You loose the 3d sorting and affine image/texture correction which the 3d GPU stuff gives for free
- Now the important bit. Marks way of giving access to OpenGL recently stopped working, so I couldn't use my own GL code. Which means attempting to figure out how and why mojo3d works. But... Mojo3d doesn't do what I want it to do. It's not open... da de da
so....

I need to take mojo3d apart, find out how it does things, and see if it is possible to rewrite the code to support what I want it to do.

Which means I will need a way to get the 3d models in a format I know and understand (write a new 3d editor) and take apart mojo3d, to see how it works and then patch it to make it work the way I want and feed all this back into the 3d editor for the 3d display.

It's not a simple case of "couldn't you just..., etc". It's not just the texturing I am doing, I am writing new 3d code, new editor code, the whole she-bang!

I work in a particular way. because that is the way I have to work. My brain isn't wired quite the same as (dare I say it) 'normal' people. I can focus down on tiny things and take apart code, but only in a particular way.

[Derron]

Sure you need to know about 3D data and how it works - yet you could have saved a lot of time just starting with 3D and do your stuff there.

With BlitzMax (or another language) you could have a raw opengl-canvas at which you could do your 3d stuff then ... so you wouldn't have needed to move from "Blitz to MX2".


bye
Ron

[iWasAdam]

Blizmax is 32bit and to be honest has some very odd bugs in it. I know there is ng but it's such a pig to get operational and i'm Not particularly fussed with it.
I am sure I could 'eventually' find a language, etc. But why? MX2 is very stable and I am supremely happy with my ide - much more than with other systems- apart from visual studio.

To be honest with you Derron, i'm Not sure you really appreciate how difficult dealing with a GPU is? Off the shelf systems such as unity hide everything from you. Let's have a raw OpenGL is simple to say, not quite as simple to do. Hence taking something that works, then take it apart and see how it ticks and see where you can make changes.

I'm certainly no advocating any language or solution, just what I am doing - good or bad? You decide...

If I wanted perfect output and instant results i'd Use unity or some other complex engine, but would I be happy or productive?