Are you using lightmapping?

[vermeer]

yay!

[Murphy]

So instead of working on the lighting and stuff, I actually took another pass at the lightmap packer.

First, I found and fixed a big ol' bug.

But more importantly, I've actually implemented the part that packs groups of polygons together. Without looking at the code, I've tried to do exactly what FSRad's author describes about how his works, and so far it's looking good. So where my old one just packed triangles, the new one will pack coplanar polygons all together. And as part of this rewrite, I added support for generating multiple lightmap textures (before if it ran out of room on the texture, it got stuck).

The only things that are missing are:
1) Splitting faces apart when they're simply too big to ever be mapped to a lightmap texture at the lightmap size and density that you've requested. For the moment it gives an error, the only solution for which is to split faces yourself in the modeler or turn the lightmap density down.
2) FSRad's ability to pack more faces inside of "hollow" parts of big coplanar polygon groups. For puh's level, it doesn't look like there's anywhere it would have tried to, really. It's no huge loss, and either way, the way my code is currently written, this can be added later without hardly rewriting anything.
3) Speed optimization. Some parts of it are mind bendingly inefficient (though it currently does puh's map in under a second).

This benefits of this in terms of use lightmap space are huge, of course. When only packing triangles, every region is half empty, after all. In puh's level, for example, this let me turn the lightmap density up 80% and fit on the same size lightmap texture! There are also quality benefits to having adjacent faces mapped together.

So anyway, I'm now pretty darn happy with this part of the code.


Here's a "pack map" of the texture space for puh's level using my old allocator/packer. You can see that each region (different colors) contains exactly one triangle. A lot of space is wasted.


And here it is using the new method:
Notice that many regions now have multiple triangles in them. For example, all the ones in the top left if you look closely contain TWO triangles (because they're split rectangles). And there's a greenish one on the top containing an interesting shape. And there's a puke green fan towards the lower right. Etc. Also notice how much higher the density is (how much bigger everything is).


Anyway, now I think it's really ready for some lighting. That'll be tricky, but I've basically figured out how I want to do my first test at it (I'm thinking light emitting surfaces but without bouncing/radiosity), and I've been putting off writing this thing for a long time because I didn't want to write the texture space stuff, and it's now pretty much done, so...

[vermeer]

FANTASTIC!!!

mega wonderful...

Ok, time for me to do a test level geometry of more complexity , and even more, building the mesh in the way would be surely more usual for artists in most packages... Would you be interested in it? probably better than the test level I did for mim/oct stuff, but nothing AAA , as I have just now though of banging some quick stuff between now and tomorrow so u can end up having it for part of the weekend if you wish...


It's all sounding simply great.

I mention as in case you may need some more complex level, with some curved surfaces and somewhat complex geometry...

[Murphy]

Ok, time for me to do a test level geometry of more complexity , and even more, building the mesh in the way would be surely more usual for artists in most packages... Would you be interested in it? probably better than the test level I did for mim/oct stuff, but nothing AAA , as I have just now though of banging some quick stuff between now and tomorrow so u can end up having it for part of the weekend if you wish...

That'd be great!
No need to rush to get it done over the weekend, but yeah, that'd be really useful when I'm a bit further down the road. Especially when I get started on curved surfaces, yeah... it'd be useful to have a map that had some. I'd been planning on just putting a sphere into your other map, but having a real-world example would be much better.

Hopefully I'll get at least a couple hours to put into this over the weekend. I may try an even simpler lighting model (no shadows) just to get something to look it.

[puh]

Cool, Murphy!

Very impressed with your work so far!


BTW, when i try to change material in MIM to materialType="EMT_TRANSPARENT_ALPHA_CHANNEL" it's not working (I use alpha-channeled tga and png as texture).
What could be wrong there? Maybe those vertices with 2 UV-s are not supported to have alpha in Irr?

If you want i can send you my current work - this house (it's also have some curved surface - terrace wall):

[Murphy!]

Sure, go ahead and send it to me. I'll take a look when I can (I still don't have Irrlicht and my MIM stuff set back up).

I'm guessing the windows are supposed to be semitransparent?

Nice model, BTW. I want a double-decker porch.

[Murphy]

Cool, Murphy!

Very impressed with your work so far!

Thanks. It looks pretty good looking at the allocation map... I hope it's actually working right. We'll see! hehehe

Maybe those vertices with 2 UV-s are not supported to have alpha in Irr?

I don't think that's a problem, but if it is, I guess that'll be some motivation to release a newer MIM loader -- the current version of the code is no longer bound to just one vertex type.

It'd always been my intention to fix that, and when I wanted to get per pixel lighting working (and, thus, the EMT_NORMAL_MAP_SOLID material), I finally rewrote a lot of the code to make it much easier to add new vertex types.

[vermeer]

Murphy, I'll do that level

I'm right now rigging a character i did promise to do (free project, too) But I'll start the level and 'll be doing while doing the other project

hehe...I should bookmark this thread instead the irrlicht main forums instead...I check this the first after all....

Puh, nice house

[Murphy]

Thanks, vermeer. Looking forward to it.

puh, I got your file. Haven't looked yet, but... when you changed it to MIM and tried to change the material type... besides just changing the material type, you'd also have needed to specify vertex colors and included an alpha component. Did you do that? Can you send me the MIM that didn't work too?


So I took a first pass at getting the UV-space back to world-space mapping and a simple lighting scheme over the weekend. The lighting is basically just the diffuse part of Phong (Lambertian?). No shadows or anything. Here are the results so far:


So the blue rectangles are ones where there's some problem with my UV-to-world space mapping, which I haven't tracked down yet. The others do seem to be working at least semi-right, though I'm not sure why they're not showing color gradation within a single surface. Probably another UV-to-world mapping problem. Or maybe I'm not calculating the angle between surface and lightsource right. We'll see...

[Murphy]

Ahh, the problem causing the invalid areas (showing up blue) turned out to be really obvious and only took a couple minutes to find. I had a Y where a Z should have been. Now all areas are working (you'll note some formerly blue areas are now shades of gray).



There's still something wrong, since the different polygons are all still solid colors, but at least it's getting closer...

Next thing (hopefully tomorrow), I'll probably try exporting it as an OBJ and seeing what it looks like just to know if it's working anywhere close to correctly.

[vermeer]

Kudos, murphy.

Seems you're nailing it

Tomorrow I'll have a bunch of free hours. I'll try to make some nice geometry I am not a level modeler, but more of a props and character modeler and animator, but hey, I like doing other stuff for a change, and your project absolutely deserves it

May i do just the complex mesh thing and pas a first version non uv mapped , so not textured, and send to you quikcly, as what you need is the geometry, cause you are generating automatic UVs on the fly, That's why is so great what you'r doing, man, the wonder of doing a level mesh and only worrying in making the base textures and base uv mapping...

Do you need me to light it? I think I can light it Blender, wings, perhaps even gmax, and export the scene together with lights features, in the main formats -ascii, of course- that support it, like VRML 2.0 or ASE.Which surely are easy for you to parse. Or maybe are diabolicly complex formats, dunno, as I don't code. For an artist's eyes, the stuff was pretty understandable in vrml 2.0 , for example. Dunno if *.wrl wreckes the quads to tris(perhaps not 2.0 ), which often is no good for lightmaps, or maybe is just only a certain package issue...but nothing to do with your own code.

Perhaps ASE wont wreck the quads, but pitty is ase is basicly only exported by Max, some support in old blender versions, and dunno what support in K3d, a tool that I actually never use. In case in the future you add a format which supports lights, I'd recommend VRML 2.0. Many packages supporting it (IE: Blender, Ultimate Unwrap (no lighting in Unwrap3d), Wings3d. )

Indeed, I think vrml 2.0 supports cameras too! And probably also cameras and lights animation. Materials, textures, and surely vertex colors. Most surely also smoothing normals, so much really important in a level (ie, curved surfaces will never look ok with out vertex normals, and normals creases... )

Much interesting.

I'll see tomorrow to bang those vertices. I didn't do on weekend as had other pending project of long time, and heard you telling me there was not so hurry, so I'll try to do tomorrow.

Big congrats

[Murphy]

I'm considering making a DLL interface for lighting solutions so that the app can serve as sort of a generic lightmapping framework... it'd take care of loading the geometry, creating UVs, saving the results, etc. And then a plugin would do the actual light calculations, so one could swap in and out various methods. Just a thought, since there are a LOT of ways to do lighting and all the rest is really just yucky gruntwork.


Yup, I don't need the UVs or any texturing. Just the geometry.

As for formats... well, OBJ is certainly good (that's all my lightmapper reads at the moment). If you wanted to include an OBJ along with whatever else, that'd be good.

As for lighting... hmm... yeah, that might be good. Just put that in whatever format you want. Also, if you felt like it, you could create a seperate OBJ with some "surface lights" in case I do some testing with light emitting surfaces. Just the geometry is fine for those... color won't really make any sense anyway.

As for quads or triangles... my current code should support arbitrary convex polygons except for a couple uncommon cases, but I haven't tested this since my test models are all triangles. If possible, send me a quad version and then a triangulated version. If you don't want to do a triangulated version, it's no problem. I can code that back into my OBJ loader (which used to always triangulate, but I took it out a while ago).

Thanks again.

[vermeer]

oops, double click

[vermeer]

I'm considering making a DLL interface for lighting solutions so that the app can serve as sort of a generic lightmapping framework...

That'd be good. yet I'd concentrate in the core thing of the lightmapper, and that other for later moment...dunno...you'r the coder

it'd take care of loading the geometry, creating UVs, saving the results, etc. And then a plugin would do the actual light calculations, so one could swap in and out various methods. Just a thought, since there are a LOT of ways to do lighting and all the rest is really just yucky gruntwork.

Dunno...I'd bet for an easy way for you first...So to get the lightmapper working. That is, if that new way is easier for you, ok then...if not...well, the actual think of setting up some lights is not that hard in wings3d and blender. true that we both by experience that when you trust in other packages, you find unexpected problems...


There are also parameters that would need to be exported...Intensity, color, etc. And..well, as you know, none wings3d or blender to a real taste of the final thing. Only Blender with raytraced shadows, but is none of what ends to look like. But even so, if you had to build on your own a full scene handler, man, would it be hard to make...is so many stuff to code... You're actually doing a powerful lightmapping system...

Hmm...

Looking at the usual options...Wings just don't cut it for an advanced light set up tool...Blender comes very near...perhaps is yet the tool for what is just the lights, as imho, that of forcing no smooth groups, the preview being after only a render, and the usual lost of details allways you export lit scene from a package to another... makes quite less "wysiwyg" than desired, though it yet be the "less worse option"...

Imho ideal would be to position lights and its setting in your tool.if connected by a simple button touch in the interface of your program, so it simply directly loaded irrlicht (or a similar interface you did for the purpose, if not depending on each irrlicht update, maybe better, that is, that would be functional with no need of user updating, as I know users get lost later one in details... ) That way you'd have full control of settings like...color...falloff (maybe inner and outer) , spotcone angle, who knows...though an spot light is nothing else than a point light projected through a cone, but the hassle of doin g the cone, linking to the light, and hding for render the cone, is quite worse than just choose "spot light"

So, it'd be much less for you. You only allow user to position and rotate light like any object. You give them an VB like roll down left menu of settings for th eselected thing (light, in this case) , so there they'll be doing tries with settings like color, con angle(when is an spot. as omnis are needed..you can go only with omnis(point light), but not only with spotlights...), and the so much important intensity...and others we may go thinking of ...
But you wont need to ouput that in your aplication, only the button will export the render data to a real time viewer, or the like, so is the irrlicht engine or whatever which takes care of the render with those changed or added settings...Dunno, is an idea.

And yup, then the actual lightmapper could be a plugin for that interface, so that people could use the interface -easier, surely- or if you add later on vrml2.0 import, they could be doing lights inBlender, or any tool exporting vrml2.0 well featured, that surely is more than one of the comercial ones. Wings would not fit as I don't see the light's intensity parameter...

Is less interactive than seeing an open gl or dx stuff (am thinking of u loading in wireframe mode the level in your interface, and the user just put the lights and moves, rotates em as wished, then set the light settings in some roll down menu.) , supporting lights and proyected shadows with color and intensity..etcaptor has done that directly in his Visual Editor program, dunno then if that's a mountain of work or not...

heck...
now that I think...
maybe join forces with the allways-gentle EtCaptor, and just do a plugin to produce lightmaps from there...
well, as you wish, I may be speaking too much as probably you prefer to do your own scene building interface so you can custom to your own coding and the settings you need to export to the lightmapper plugin in the works. I don't know how to code, that's why I often speak without any knowledge of certain matters.perhaps he's using one of the latest irllicht versions embeded inside his editor, or something.

Yup, I don't need the UVs or any texturing. Just the geometry.

Oh! fantastic. I'll try and do something good

As for formats... well, OBJ is certainly good (that's all my lightmapper reads at the moment). If you wanted to include an OBJ along with whatever else, that'd be good.

cool, is my favourite static mesh format

As for lighting... hmm... yeah, that might be good. Just put that in whatever format you want. Also, if you felt like it, you could create a seperate OBJ with some "surface lights" in case I do some testing with light emitting surfaces

fabulous...Ok, i guess you can kill the rendering of that helper geometry later on..fact is...well, doing in blender, I must force that geometry not project shadows or oclude other light sources itself..I think is doable in blender (it is very easy in Max or gmax...) ?

Just the geometry is fine for those... color won't really make any sense anyway.

light color will not be supported, then, or just in this stage ?i think fsrad based on emitting materials, so color of light was based onmaterial color, in teh un modified fsrad version.(you later on supported light color feature of blender)

s for quads or triangles... my current code should support arbitrary convex polygons

BSP style? That is, no single sided faces, or isolated vertices I suppose. Curious, is the standard export of Wings, due to its internal winged edge structure, it can't output bad geometry in that sense...Only if you use "hole material" and export for example as obj. It simply deletes in export anything with hole material.You can achieve any mesh with wings, indeed, against what some may think.

game levels are usually done with convex geometry. cloth or Flags of single sided faces, or vegetation that is single side face, and then rendered by the empty side too, are added as props, often, not as actual level geometry. Depends on the engine.

but I haven't tested this since my test models are all triangles

No issue. Every modeler have a triangulate option, and some even can only work with tris

If possible, send me a quad version and then a triangulated version

easy thing the touch of a button

[Murphy]

Imho ideal would be to position lights and its setting in your tool.
...
That way you'd have full control of settings like...color...falloff (maybe inner and outer) , spotcone angle, who knows...

Yeah. My first version is going to be sort FSRad-ish in that it won't have much of a user interface for doing setups. But, yeah, ideally it'd really be done in the tool or with a program written just for it, since the lighting calculations will be specific to my program and it'd be nice to do a preview and have settings that make sense.

For the moment, my thinking is that when I get radiosity working, I'll probably do a file format similar to OBJ which will contain lighting data (the sense of basing it off of OBJ is that the lights will just be polygons), and probably do a Blender exporter so that you can at least kind of set up lights properly in Blender. They'd be an entirely seperate mesh from the REAL geometry, so that they wouldn't be rendered in the final output, and the fact that Blender doesn't have vertex normals wouldn't be a problem (that is, you could model the real level geometry in a modeler that DID support vertex normals/smoothin and just do the lights in Blender).

now that I think...
maybe join forces with the allways-gentle EtCaptor, and just do a plugin to produce lightmaps from there...

Indeed, if someone working on a visual editor wanted to include adding explicit support for my lightmapper down the road, I'd be very interested. When and if I get it to the point that it'd be worthwhile for anyone.
(If someone wanted to include support for modifying materials -- adding Irrlicht-specific materials -- and then saving as MIM, I'd be interested in that too )

light color will not be supported, then, or just in this stage ?i think fsrad based on emitting materials, so color of light was based onmaterial color, in teh un modified fsrad version.(you later on supported light color feature of blender)

Oh, color will definitely be supported.
But it isn't yet, and I can assign it myself anyway.
My eventual lighting will be based on emitting materials too.
The material colors as light colors... I guess it's not so bad now that I think about it.
And yes, my Blender exporter exported colored point lights. I never really messed with explicit emitting surfaces in FSRad (I did indirectly, because internally FSRad converts point lights to emitting surfaces).
As a sidenote, at least with the radiosity method I have in mind, I don't think I'll be able to fake point lights the way FSRad did. Not well, anyway.

BSP style? That is, no single sided faces, or isolated vertices I suppose.

Yup, pretty much. Three or more vertices is okay, as long as they're coplanar and convex, which is pretty standard. Eventually, I'll write the code to split concave polys into multiple convex ones, but I haven't yet.
Though now that I'm thinking about it... I think convex ploys may actually work. They'd waste texture space (the concave parts wouldn't get filled in), but I think they might work.


So, I've been unpleasantly busy (and will continue to be so for at least the next few weeks), but I did set aside an hour today to work on it. I'd determined a few days ago that it was, indeed, the UV-back-to-world-space mapping causing polygons to appear as solid colors. I had an idea yesterday of how to go about it better, and took a pass tonight at implementing that.


I'm sure there are still problems (edit: I just fixed one, though ), and I know a lot of my math is sloppy and should be "tuned up". But it's definitely working better than before!

So really, my next steps are to write the texture image cleanup code, and then try exporting this all and seeing what it looks like...