The Roadmap...

Get help with installing and running the Cafu Engine here. This forum is also for general questions and discussion of all aspects regarding the Cafu Engine.
Post Reply
HWGuy
Posts:95
Joined:2011-05-31, 07:37
The Roadmap...

Post by HWGuy » 2012-01-07, 19:33

Soo, my poorly made tiered ticket roadmap... oh boy, there's a lot of work to do.
I can handle the big xx, Thomas will be helping with Graphics and some other things.
Oh poor Carsten, have any commercial or even notable titles come out of Cafu? I intend to change that.
Image
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Re: The Roadmap...

Post by Carsten » 2012-01-08, 20:23

Hi HWGuy,

that's an interesting image, thanks! :cheesy:
(As a side note, it should be possible to group the tickets directly in the Trac ticket system as well, e.g. by assigning proper Components and Milestones... then in View Tickets, try e.g. group by: Component)

In any case, I'm currently working a lot on finishing the Model Editor, which will happen real soon now.

Immediately after that, I'll get to work with Thomas on the new OpenGL 3+ renderer, so things look very good overall! :up:
Best regards,
Carsten
HWGuy
Posts:95
Joined:2011-05-31, 07:37

Re: The Roadmap...

Post by HWGuy » 2012-01-08, 23:52

Thomas is a little busy with University this time of year, but since he's been studying the engine it shouldn't take too long for the basic implementation, after that it's just a case of plopping in features one by one... I'm thinking having the best looking real-time lighting should take precedence over next-gen cliches... also "real-ish" HDR, no fake HDR.
Since you've written a paper on lighting I'm sure you understand the value of good lighting... it can make graphics amazing even with bare minimal texturing and modelling.

I'm also looking into getting some more help... it's hard finding good programmers.
Maybe I'll give up doing that and look into... you. Buying CFS shares to support development, although I'll be working less and spending time on developing assets for the title and tech demo.


For the new lighting I've been thinking... an overly simplistic take on reality rather than the mess all next-gen engines currently do it.
Textures could have new variables in the .cmat so they look better in HDR:
"Albedo" - 0 to 65536 - Since the textures are RGB8 there should be a variable to control how they interact with light of varying intensities, this would affect how much light it reflects, perhaps how much light it takes to wash out as well since it could double as a "re-emission" factor.
"Dispersion" - Since spectral dispersion is impossible in raster(even impossible in raytracers, it's faked), this simply refers to how, although the specular map could simply be averaged to give a default factor, since a very shiny thing bounces light more directly than a matte one... also doesn't convert as much light to it's own colour.

The graphics could be RGB16 squished into RGB8 by simply dividing by a factor and adding/subtracting for an Exposure Value and shutter speed(or should i say f-stop) faked all in one... HDR could literally be nothing more than a shader which turns the game which is RGB16 into RGB8 with two input variables which are created based on the brightness of a few sample points, just like how a digital SLR works.
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Re: The Roadmap...

Post by Carsten » 2012-01-09, 12:31

HWGuy wrote:I'm also looking into getting some more help... it's hard finding good programmers.
Maybe I'll give up doing that and look into... you. Buying CFS shares to support development
That's a very nice thought and certainly welcome -- but if you want it to be really effective, then get more programmers. This is really the most important resource that we need to get features implemented, tickets closed, etc.
For the new lighting I've been thinking... an overly simplistic take on reality rather than the mess all next-gen engines currently do it. [...]
Well, I'm all open for new ideas in lighting and HDR in particular, but we'd need concrete details, (OpenGL-)extensions(-specs), papers, etc. in order to implement something. (I've not yet done any web research regarding HDR myself...)
Best regards,
Carsten
HWGuy
Posts:95
Joined:2011-05-31, 07:37

Re: The Roadmap...

Post by HWGuy » 2012-01-09, 14:42

Carsten wrote: That's a very nice thought and certainly welcome -- but if you want it to be really effective, then get more programmers. This is really the most important resource that we need to get features implemented, tickets closed, etc.
Yes, I'd only be looking for programmers, I could do everything involving assets myself. A couple good ones I know are busy with University/College right now, but they seem interested.
Carsten wrote:Well, I'm all open for new ideas in lighting and HDR in particular, but we'd need concrete details, (OpenGL-)extensions(-specs), papers, etc. in order to implement something. (I've not yet done any web research regarding HDR myself...)
I don't know the specific extensions by memory that would support HDR, but there's a list of datatypes which you'd need in the spec sheet and that's about it.
OpenGL 3+ can do real HDR with ease... most games still fake it because consoles only support OGL2(OGLES2)/D3D9 with a few extensions.

If I'm making sense of things I can boil down things to a short description:
R11G11B10 Lighting(lightmaps and vertex lighting) mapped to RGBA8 textures/vertices and displayed based on a simple equation(linear/exponential/logarithmic, depending on how you want things to look) with a factor based on sampling the intensity and averaging it with a simple points/numberofpoints or exponential/logarithmic averaging. Interpolate the exposure factor to give the iris adjusting over time effect.
If you make the tone mapping equation a bit more complex you can have a customizeable curve to give great results.
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Re: The Roadmap...

Post by Carsten » 2012-01-16, 20:32

As our Radiosity computations in CaLight inherently produce physical quantities that are tone-mapped to lightmaps, I guess that we here have a very good source for HDR values as well...
Best regards,
Carsten
HWGuy
Posts:95
Joined:2011-05-31, 07:37

Re: The Roadmap...

Post by HWGuy » 2012-01-16, 23:52

Carsten wrote:As our Radiosity computations in CaLight inherently produce physical quantities that are tone-mapped to lightmaps, I guess that we here have a very good source for HDR values as well...
In that case all you have to do is store the values at a higher precision and adjust the tone mapping to make CaLight HDR-compatible. :)

Although with higher precision come larger file size, you'll probably have to figure out a way to optimize the lightmaps so the lowest possible resolution is used, while giving the illusion of extremely high resolution...
Could make things look extremely good even with the existing system by resolving two problems, stair-steps(perhaps lightmap resolution based on how sharp the changes in values are) and edge "artifacts"(places where something should be in shadow isn't because the sample point can see light, most obvious where a pole sticks out of the ground).

Could have vector(model projection) lightmaps which are then rendered into traditional lightmaps with GPU-acceleration(deferred rendering), you can then have the resolution of those vary depending on the user's graphics settings.
Vector(projection) lightmaps would be soo cheap computationally that you could have realtime lighting that looks even better than CaLight currently does... and have the system API-agnostic so OpenGL or DirectX could be used to do the deferred rendering which turns the CPU derived vectors(projections) into lightmaps.

Wait... must use right terminology... vector... model... projection... shadow volumes!
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Re: The Roadmap...

Post by Carsten » 2012-01-18, 16:32

I'm not sure if I understand everything you said, but in any case, what we're really lacking is an implementation of all this. :cheesy: ;-)
Best regards,
Carsten
User avatar
Haimi
Posts:85
Joined:2011-11-23, 09:28

Re: The Roadmap...

Post by Haimi » 2012-01-18, 21:01

As I want to extend my C++ skills, I think I can use my semester break in Feb/Mar to contribute a little... Maybe I can manage to get the whole buch running on Mac :D
Project Status: Code architecture definition
6 Programmers, 1 Photographer, 1 Architect, 1 Game designer
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Re: The Roadmap...

Post by Carsten » 2012-01-19, 20:45

Haimi wrote:As I want to extend my C++ skills, I think I can use my semester break in Feb/Mar to contribute a little... Maybe I can manage to get the whole buch running on Mac :D
That would be awesome -- and very much appreciated! :wohow:
Best regards,
Carsten
HWGuy
Posts:95
Joined:2011-05-31, 07:37

Re: The Roadmap...

Post by HWGuy » 2012-01-22, 13:31

Perhaps look into using Qt for making Cafu multiplatform, then a single source could be used for all 3 platforms quite easily... well, it's possible making Cafu for Windows/BSD/Linux/MacOS/Symbian/Maemo/Android with a single Qt Creator project, but you'd have to dig through the dependencies of Cafu, bundling some and some could be easily replaced.
Otherwise, you should be able to port over the Linux build quite quickly.
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Re: The Roadmap...

Post by Carsten » 2012-01-22, 15:34

HWGuy wrote:Perhaps look into using Qt for making Cafu multiplatform
We use excellent wxWidgets framework for this purpose already, which (compared to Qt)
  • requires no custom preprocessing before the code can be compiled,
  • is much more lightweight,
  • uses the native system API and widgets (applications are true system applications everywhere),
  • has the more liberal license.
I'm not perfectly happy with wxWidgets either, but at this time, there is no compelling reason to switch to Qt (which would be possible, but require an awful amount of work, and doing so would not ease the transition to Mac OS X).
Best regards,
Carsten
HWGuy
Posts:95
Joined:2011-05-31, 07:37

Re: The Roadmap...

Post by HWGuy » 2012-01-22, 23:38

I got sucked into Qt because of the IDE(one of the few I can tolerate) and huge amount of existing stuff bundled in which would normally require dozens of added on which I'd have to deal with... it's why it's soo big, it's not just an accelerated GUI kit.
Qt is LGPL and wxWidgets is... a custom license, says it's like GPL with a binaries exception.

Does wxWidgets have a graphical designer? I guess that's the only thing Qt has going for it unless you made use of the huge library of stuff built in... which would bring no advantages(well, some tiny ones) and be a huge amount of work integrating.

EDIT: So, I've taken a look at wxWidgets, and I'm delighted to see something that didn't exist last time I looked, a graphical designer, and better documentation. I'm compelled to study it.
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Re: The Roadmap...

Post by Carsten » 2012-01-23, 12:30

Yes, it has several graphical designers.
Probably none of them is as powerful and as convenient as the Qt designer, but I don't mind much: For me it's important that I can "program" very nice dialogs directly in C++, so I tend to use the designers only to generate the initial C++ code (except for the really large dialogs, where I'm more careful to be able to re-generate the code).
Best regards,
Carsten
Post Reply

Who is online

Users browsing this forum: No registered users and 20 guests