Are you using lightmapping?

[Murphy]

That was me earlier, obviously.

So, here's a comparison of some renderings with various hemicubes. From left to right, they are: 128x128, 300x300, 128x128 with 6X antialiasing.


See how much nicer looking the one at 300 looks? The gradients are a lot smoother and you don't get the weird bar effect. The 128x128 with antialiasing looks almost as good and doesn't take much more time than the 128x128 without antialiasing on modern hardware. Like I said, antialiasing can't be used on subsequent passes, but since the light is more diffuse to begin with at this point, it might not be noticable anyway. I guess we'll have to wait and see.


Going back to the question I posed earlier: my original "project roadmap" says that I should work on implementing bouncing now. But I'm considering trying to rework the project a bit and try implementing more of it on the graphics card in hopes of improving speed. If you have feelings on the subject, please feel free to weigh in. It might be a while until I work on it again (don't really know).


A random thought:

The way the current code is, I can't use SSE instructions (for those of you unfamiliar, these are similar to MMX processor instructions, but for floating point math instead of integer math) for the first pass, but I realized yesterday that I COULD use them for subsequent passes. This may well mean subsequent passes get considerably faster.


Vermeer, I'll definitely be playing with your scenes at some point, especially once I start playing with vertex normals (which aren't currently implemented, but will be at some point... they'll just slow things down now anyway, which doesn't help my testing and development!).

[cmoibenlepro]

That's absolutly great!

I don't know anything about sse optimisations but I suppose it would be a good idea.

[pfo]

Guess I'll throw my 2 cents in: It looks like you've got really nice algorithms and ideas in place to make a nice lightmapper, speeding up the process seems to be key at this point. This would only benefit you more when you add more features to it (less time spent waiting for a test to finish), and of course will make the tool more usable for everyone. Keep up the good work, it's looking very nice

[vermeer]

hey,

Have loaded the scenes here...

nice proyected shadows

i like the way it seems to be distributing the light, as a base

The pixelated diagonals in shadows are to low resolution of those areas, but mostly, as low resolution of the whole bitmap

The sparse look like made of like bubles of lights...looks like when in xsi you choose too few photons...you have several values, one is the number of photons, other how much do the melt between them... sorry if I don't remember the tehcnical words...also, the size of a GI light in most renderers usually when incrreased in size -a concept wich is not the falloff, but an strange value of gi lights- you get smoother and more real lighting, more "gi".

In max there are values like shadow integrity and shadow quality which I don't know how are translated to these terms...


In xsi is all about emitters, and the way photons bounce all over there, energy , how many photons, etc.

Imho, those results are ina very good road, probably getting the light with more "photons" , or whatever they are, or like more melted, will make look better the projected like of the door, and the edgy pixels, the "stairs" , just the usual need of much more pixels, so, bigger lightmap, or the use of several to use for a room, like fsrad did. Dunno...


In max you can get those results of like step gradients in some areas when you used very liitle samples, and no spread, well, lots of values.

What i know is depending on what you apply you can get a fast result that actually doesn't care much about realism, bus is all an antialiased blur, or a way better gi like render, which actually gives it "that " feel, by changing certain area light or other values. The number of "elements" and how they melt between them, is key, surely, and how the bounce, etc.

I'm a noob in GI rendering, but well, in case can be of any help.

BTW, fsrad did a good work on that "feel" so if you are using something similar, no doubt it per se will look good

Anyway, imho the most interesting fact of your lightmapping, is the automatic packing of uvs and lightmaps, as if based in fsrad one, that can be so much better than max automatic one, and than several others.And is ...key for ie, lightmapping a whole neighbour hood level...Or a full town.I mean, when not doing tricks and modular stuff.

I'm eager to grab one beta, hehe...

don't worry, go at your pace, is just getting me more and more curious...

[Murphy]

This would only benefit you more when you add more features to it (less time spent waiting for a test to finish)

This is certainly a good argument. One of the ones I've been considering. Though it does mean it'll be longer until I'm to the point of adding more features.

My current thinking is to do a couple experiments and see how feasible more hardware acceleration is. If I can move enough into hardware, I should be able to use antialiasing even for passes besides the first one, which is almost equivilant to using a bigger hemicube, but at much less cost (in terms of time).

The sparse look like made of like bubles of lights...looks like when in xsi you choose too few photons...

Yeah, the reason for this is different but somewhat similar. You'll notice that this effect is much less dramatic in the one rendered with a bigger hemicube -- this is similar to adding more photons. I think you may be able to take one of the shots I posted above (the 300x300 lightmap texture, for example), and change the MTL I posted earlier to reference it instead and you'll see that it looks considerably better. I'll post a better render complete with OBJ and MTL sometime later.

the size of a GI light in most renderers usually when incrreased in size ... you get smoother and more real lighting, more "gi".

Yes. In theory, a point light will only give you very sharp shadows (at least until the light gets bounced around some, radiosity style). A bigger emitter gives you penumbras because there are places where SOME of the big emitter is in shadow and some isn't. They also cast more light and in a bigger area. BUT, their light does get "clipped" by other things -- for example when going through a tight doorway. After this, the light is essentially smaller.


Another important thing to remember, though, is that so far all the scenes I've posted were direct light only -- no bouncing. Not really GI. When the light starts bouncing around, it should even stuff out some more.

Anyway, imho the most interesting fact of your lightmapping, is the automatic packing of uvs and lightmaps, as if based in fsrad one, that can be so much better than max automatic one, and than several others.

I hope the lighting will be cool too. But I should release a tool which will automatically generate UVs for an OBJ.

[vermeer]

very interesting post to answer in detail, but it caught me way to late at night, i'll catch it again once come back tomorrow after my graphics long day job. And will eply well in detail


yes, I indeed had actually used those jpgs to test th e3 of them; in Ultimate unwrap is inmediate, only had to delete the roof from the building . Some sconds.

I saw differences, but better if i reply all tomorrow

[Eternl Knight]

Pretty good for a first pass scene. I'll hold off on the FSRad speed / quality comparisons until you get reflection / bouncing implemented (after all - FSRad spends most of it's time doing the bounces).

I have a few more research papers on GPU processing if interested. One looks very good actually (although it DOES use GLSL shaders - so you might not want it). I trawl through SIGGRAPH papers & presentations when I get time and thought that this one (with it's 99% GPU processed radiosity) might interest you. I also located some of the papers it references in my articles CD's if you want some background.

--EK

[Murphy]

I have a few more research papers on GPU processing if interested. One looks very good actually (although it DOES use GLSL shaders - so you might not want it). I trawl through SIGGRAPH papers & presentations when I get time and thought that this one (with it's 99% GPU processed radiosity) might interest you. I also located some of the papers it references in my articles CD's if you want some background.

Ah-ha, so I was right and it can be done on modern hardware. I've got no problem wiht GLSL. I'd definitely be interested. Are they rendering hemicubes? I'd assume so.

I've been putting continued thought into this myself. I should at least try getting the first pass done on the card and seeing how fast it is. I think I'm going to need to get a book on GLSL...


I did two little tiny experiments yesterday. One was to do with the data transfer between the card and the computer (during which I realized I made a crazy stupid mistake and was re-allocating a chunk of memory over and over! fixing it made hardly any difference in speed though), and the other was rendering the hemicubes at random orientation. This did, indeed, get rid of the weird striping and stuff, like I thought it would... at the expense of making the texture very "grainy". Of course, a little blurring... anyway, may come in handy. Especially for previews. Render with a tiny hemicube. It'd look crazy, but the light would be basically correct. Take a look.

[Eternl Knight]

Yes - they use hemicubes (easist method for SIMD processing all thing considered). Give us an email address and I'll send them along

As for the grainy images - it reminds me of photon-based lighting. And as it is possible to smooth out the lighting using it - I would use one of the methods from that line of GI for making the final radiance pass.

--EK

[puh]

Murphy: how did increased the rendering time for the last image?

[Murphy]

puh, the rendering time for the last image (128x128 hemicube with random orientation) is practically the same as for the plain 128x128 hemicube. The random orientation one is just one additional call to glRotatef().

[vermeer]

tested that new one.

yes, it looks a lot like when rendering with XSI, when setting few photons, which is good usually to test how light is distributting... One can end up in very realistic setup, but usually is time consuming the setting up till you get a nice result, at least in my case...Am a noob, also, in GI.

It looks like you are getting near...

[vermeer]

I dunno if these links can be of any help.... (glsl) :

http://www.3dshaders.com/shaderLinks.html

[Murphy]

It looks like you are getting near...

Only for the first pass!

Moving stuff into the GPU and multiple passes is still a ways off.

[fo0z]

Sorry to beak this thread with a basic coding question ... however ... how do you paint the background lightmap image with a custom color ( other than black ) ?
( I am working on fsrad too ... )

Thank you !