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.
that's an interesting image, thanks!
(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!
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.
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.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
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...)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. [...]
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: 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.
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.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...)
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.
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.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...
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!
6 Programmers, 1 Photographer, 1 Architect, 1 Game designer
That would be awesome -- and very much appreciated!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
Otherwise, you should be able to port over the Linux build quite quickly.
We use excellent wxWidgets framework for this purpose already, which (compared to Qt)HWGuy wrote:Perhaps look into using Qt for making Cafu multiplatform
- 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.
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.
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).
Users browsing this forum: No registered users and 3 guests