I am using default media and it seems that if I bake the light maps the building
models scale larger. Also in the same map the trees leaves loose transparency.
Does any one know if this was fixed because it still happens in my map.
If it is a problem with the default models why have they not been fixed by now.

There is no fix to this yet as far as I know. Lightmapping is still being worked on and this is not an issue with the models themselves.
There is nothing you can do from your end about this. I'm having the same problem with models being rescaled, misplaced after a bake which is why I don't use it yet. Here is hoping for an update on this sometime this year



-Wolf

If they are default media, send Lee an email and let him know. I have had objects scaling incorrectly in the past and he has fixed them up. Obviously default media should all work, so he would have no issue with this. I seem to remember a fix in the fpe for some of these issues, but it could have been another problem, things change all the time in GG.

i gave up on it to be honest no baking seems to fix the ridiculous resize with baking, my houses and dungeons were only big enough for ants think spinal tap and the druids dance around stone henge

I do not understand how baking a light map would change the scale of an object. This would seem to
be some sort of spaghetti code on Lee's part. Baking a light map does not require changing the object in any way.
This is a major bug and should of had some attention a long time ago.

I've had that issue for some time but only with a handful of (third party) models. Many would scale up such that they were larger than the map itself! I just stopped lightmapping. I know that isn't the way it should be, but it was the quickest fix, and my performance is actually better with real time lighting. The only bad part is I (obviously) can't bake static lights, so my levels look pretty generic.

EDIT: Lee is aware of the problem, but I think he believes the issue is with the models themselves, because he offered to take a look at my models once upon a time. I, being the procrastinator that I am, just never got around to mailing them to him.

This usually happens when a scale value of other then 100 is in the FPE file.
Duplicate the object and change the name, Open the FPE file in notepad and set the scale value to 100, or delete the line completely.

Save the file.

Now when you place it in the editor, you can scale it the way you want, then light mapping should not affect the scale anymore.
The only other thing that messes with the lightmapper, is multi textured objects without the texture statement blank in the fpe file. Now if you are using multi textured objects, the light mapper will only use the first 6 assigned, any after that will be the first texture assigned in the x file.

Another statement can be tried, resetlimbmatrix=1 might help fix the issue also.

None of these suggestions have helped. Can someone check the House1.x model in the medieval category?
I can not find anything wrong and since this is default media it should be up to Lee to fix if it is the model.
I still believe this is a bug in the game guru code.

Hmn, that model isn't scaling when light mapped for me.

I just tried House1 and it doesn't scale on me, either. In fact, I tried the lightmapper on a few of the other models I had issues with and they no longer scale, either! LOL, I hadn't tried it in probably a year. Oh well, performance is still better without it.

I figured out the problem, the house1.x model has 3 bones that have scaling.
If the bones are deleted or the scaling for the bones are set to 1.0 in a modeling program
then exported the model will light map okay. Lee must be loading the model at the beginning
of the light map process and not checking if the bones have scaling. He must handle this in code
or require a fix of all the models default or third party. Otherwise baking static lights is broken.

@Stab in the Dark software . Well done ! great find, interesting fix.

Just checked that model from my collection and i'm not seeing any bones, maybe it's been updated but you still have the old models.

I just checked that model and it does have three bones and they are scaled, yet it doesn't scale in my editor when lightmapping. It also doesn't have resetlimbmatrix in the fpe. Curious!

Hmm, Well the mystery deepens. I wonder why it works for some.
I think what is happening when the light mapper code runs thru the models limbs it is
including bones which are considered limbs in DBPro. He needs to do a check if the limb
has mesh data if not it is a bone. But this may not solve the problem because any vertices
assigned to the bone will get scaled by the bones scaling. Personally I think bones should not have
any scaling because it is not used by GG, but removing it from all models is not a practical solution.
It should be handled in code.

GameGuru isn't DBPro any more, it was converted fully over to C++

I am sorry to disappoint you but putting it all to C++ does not stop it from being DBPro.
DBPro was always C++ behind the scenes. GG still uses the DBO object format which is how the
objects are handled.

Isn't a 3D model format irrelevant to the coding language of the software?

Sorry guys, I can't find these bones.
I've searching via "bone tools" in Max, and it say "selection is not a bone object", for each mesh.
In fact there are 3 meshes:
1-house_botton
2-doorway
3-door

Just the door appears with X axis as scaled.

I'm curious why do you want a bones, in a closed house.

3com

Exactly what i'm seeing. Looks like we all have different versions of the same model. That is odd in itself.

Those show up as bones in Fragmotion and Ultimate Unwrap for me

Jerry, you are right, Fragmotion talking about bones if you are in skeleton tab, and about meshes if you are in model tab.

Anyway I've encountered looking model most in deepth, via Max, than there is some isolate poligon, maybe had missed y the model author. Please refer to the vid, so you can get better my point.

Also I've noticed in X file it is a texture file named "house1atlas_D.dds", but "house1_D.dds" in fpe file, as diffuse map; I've removed isolate poligon, re-set texture as "house1_D.dds" in 3ds Max, and it works.

About testing in LM, well, my comp does not work fine with lightmapping, so I can not test it.



Thanks for watch the video.

3com

Isn't bones but dummies converted on import, at a guess something auto generated by GG for widget to use for rotate and scale in editor. Might be wrong but seems logical to me since these would be generated at a single pivot point for individual meshes.
If there are three meshes unattached it would create three dummies even if exported as a single model from modeling app, it doesn't matter what the .x refers to for texture this would be overridden by the fpe.

That makes sense, thanks!

If I am right about this then it would be a simple case of attaching all separate meshes before export so only a single dummy is required, it wouldn't affect the model in any way and if using a single texture would be the right thing to do anyhow rather than telling GG there are three separate objects to lightmap when there should be only one.

Always best to collapse the meshes before export. Seems to work better that way.

That's what I did.

I think that the fragment found in the model, influences when calculating the coordinates, by GG gizmo.
Not 100% sure, but it is a stock model.

3com

I agree, I always join my objects into one when I export to .x, I've had far too many models mess up because they were made of multiple objects. Some of my models that were made of multiple objects literally fell apart into separate pieces laying on the ground when I imported them into GG lol.

So the conclusion is that some models have bones that have scaling and these bones have vertices
assigned. The vertices are being scaled by the light mapper by the exact amount of the scaling on the bones
the are assigned to. We have confirmed what the bug is now it is up to Lee to fix in his light mapper code.
Would be good if a mod could bring this to post to Lee's attention so we can get this fixed ASAP.

It's not really a bug in the code though, i'm pretty sure the same issue occurs in other engines too, I know sometimes in unity if you had a model with these issue it would refuse to light map the model.

It's badly made models that need fixing, all you need to do is load them into an editor and either set the scale (basically reset the scale of the parts to 1.00 while leaving them the same size) of the objects that are scaled wrongly, or merge the objects into one and set the overall scale.

This is something a proficient modeller should have done in the first place, which is why Lee was asking people to report any models this happened with.

I always apply location, rotation, and scale on models. I read it somewhere a long long time ago that it was best practice, and now I know another instance of why! Good thread !

Actually it is. As a programmer I know that he should be doing a check and excluding
scaling. It is a simple fix on his part and should definitely be considered a bug.
This prevents the average user from using static lights which basically breaks
GG.




Yes, I know I am the one who posted the fix in this post.

There is a lot you could say about the way GG should handle models but you can't please everyone and for modelers there isn't a lot to go on so far, most of it can be speculation and guesswork as to what is going on among all those wires hanging out the back of the engine.

This isn't entirely the Artists fault as GameGuru may change a lot whilst in progress and those models may need different requirements as things move along. Just the same as code changes mean changes to other areas of the code.

If it is a modeling issue it shouldn't be hard for the original author to fix, but they can't fix what they don't know is broke nor can they predict what may be required down the line. Things will settle down eventually and users need to be patient with the Artists as much as they do the Dev team. Anyone creating media for GG right now is caught between a rock and a hard place as you don't know whats going to get broken next.
One thing I can assure you of is that Lee gets right on it if anything gets busted, but just like anyone else here he can't fix till he is informed. I believe he is having back problems right now which causes him a lot of pain so he's having to rest up a little this past week or so.

I have discovered another problem with the light mapper.
In order for the light mapper to work correctly on an entity(model) it can not have any overlapping
geometry in the UV map. If it does the light mapper will put shadows on faces that should not have Shadows.
This is technically not a problem of the light mapper and more a problem of the models not being made to
a specific standard to give the correct results in GG. In my opinion this is not something that should be handled
in code by GG. Unfortunately a large percentage of the default and store models have at least one of the 2 problems
I have mentioned in this post. This creates a bad experience for the new user who does not understand the technical problems. Since most GG users rely on the default media and also the store media it should have been in the best interest
of TGC to have created a standard for the models that would work correctly with GG. In my opinion it would be best to remove the light mapper from GG and add dynamic lights instead. Although I will admit that on correctly made models the light mapping looks way better then the dynamic lighting. I have attached a screen shot of a model light mapped showing the
problem with over lapping geometry in the UV map. Hopefully Lee can consider himself well informed now.

Models are not approved to any less a standard than any other engine out there, stricter than some. In fact I will lay odds on it that if you took any of these models into FPSC Classic and baked lightmapping you would find nothing wrong with them. What would be the specific standard for models for GameGuru, are they different from other engines? If they are I would be interested since this is the first I heard.

It is very simple, if the light mapper only works correctly on models that do not have overlapping geometry in their UV
atlas then the problem lies with the model. Since Lee created the light mapper he would know this and should have set a standard
for at least the default models. FYI it is an industry standard to not have overlapping geometry in the UV atlas for light mapping.
This also creates a problem with static lights being mapped to the object. The conclusion is that he did not even test the
default models to determine if there was a problem. For example the house1.x model ( discussed previously in this thread )
it does not have a proper UV atlas and can not be light mapped correctly. It would seem to me that this is a major problem
but I doubt it will be fixed. Maybe TGC artist can take note of this post and discuss this at the next meeting before creating more model
packs. Unless the GG user creates all of their own models correctly or fixes the default models they will not get good results.
Also as discussed in the beginning of this thread the models bones having scaling can and should be handled in code by GG.

Thanks for the info
So your suggesting no overlapping uv's in the model for lightmapping as industry standard, wont that mean no sharing of texture over uv's which means massively increased texture resolutions across the board? I always thought it required a second uv channel which is generated by the lightmapper itself, or in the case of some engines by the Artist in modeling app but I don't claim to know it all. All the same this second uv layer doesn't require the high texture resolutions since it is an overlay so uv islands can be spread out and not overlapping while the original diffuse uv's remain untouched, that is how it is supposed to work as industry standard.

In this case the lightmapper is in error not the models. Unless Lee changed the way GameGuru is supposed to handle the Lightmap uv channel and I haven't heard anything about that so won't argue about it. However fixing it by giving islands their own uv space is done in the second channel only so texture sizes don't get out of hand.

At the moment I can only confirm what changes I have made to the models to get the light mapper to work
correctly. It would be nice to get some feedback from Lee instead of this guessing game with trial and error
until we get a result that seems to work. I am a little concerned about the new DLC packs if they will work correctly.
As a GG user I am trying to help figure out what we need to do as users to get the best results.

Why would you be concerned?

As I understand it the models that have this issue are old models that were converted over from FPSC classic when they started the FPSC:R project so I would guess it effects only the free models and maybe the first couple of DLC's, if so then any DLC after that is new and created specifically for GameGuru so is unlikely to have the same issues.

It is not only old models that have an issue. I have tested new DLC packs since it became GG and
the problem persists so your statement is incorrect unless you can prove it by showing a screen shot
of a model light mapped correctly. By the way the model I used in the screen shot above to show it does not light
map properly is the model Lee used while coding the mapper.

P.S. Which DLC packs do you think do not have this issue?

Hmn, I was just guessing to be honest. You would have thought that new models would have been made better. Have you checked all of the DLC's? Because thinking about it, I think the only new models in the DLC's are the sci-fi ones and the updated fantasy ones they added recently, have you checked them?

Totally agree. Larger models with a bunch of islands, can take long texture size, if we has to give their space to each island; and here we are going to run into "perfomance", loss fps, GG running slow, and so on, all is connected here.

A question:
My fault, I do no try LM often, so I've a question:
If I gives light and shadows to my scene, lets say in 3ds Max, and export as X file to GG:

a- does LM takes those lights and shadows?
b- Simply ignore them, and create their own?
c- X file is a very old system, and does not work with.

Thanks in advance.

3com

There should be a lightmaps folder in the levelbank somewhere, I don't have time to go digging around right now, as I remember it you will find .dbo meshes in there and the lightmaps which are auto generated uv layouts. It appears that the GameGuru lightmapper is generating actual models unwrapped in this case and these are numbered not named so no way I can think of to ensure these correspond correctly to each other unless the numbers are related to when object is placed which means a lot of tedious time and effort to go through it all. So no easy way, I have heard Lee refer to these as 'Glass' overlays and it explains the problem with the lightmapper producing more overlay meshes when LOD comes into it. The lightmapper is broken in more ways than one and it isn't anything to do with Artists not making models to industry standard.

I will also reassert my opinion that if Artists don't make their models to scale before export, and scaling, sometimes in the thousands in the fpe then it will inevitably cause issues and not only with lightmapping, none of this is guess work and simply the way it should be done.

Hey Lee, how about some feedback so we can figure out what the criteria should be to get the
models light mapped correctly.

Just a bump to keep it relevant.

Hmmm ... very interesting and informative thread ...

I've always used overlapping UVs in order to optimize the texture usage ... especially for "non-critical" parts of the mesh. Maybe I'm too old-school for the ways things are handled these days.

But generally, I would agree that there are some aspects of the LM that are not yet working correctly / reliably. As a matter of fact, I had put together a test level and used some of the new models I bought (dungeon pack) and the LM produced a "strong", harsh shadow from a door, projected onto the floor tile ... which just doesn't look right, anyway I look at it ...

Cheers,
Fendrik

Thanks for the bump I dropped in a House1 entity as static, and then one as immobile dynamic for comparison purposes. I used test game then F2 to light-map the scene and I have attached the result. Can you send me a screenshot from a similar perspective, along with the FPM you used to produce the shot (and perhaps the House1 entity files so I can compare against what I have here?). I am using V1.121 to make this shot. If I can reproduce it, I can fix it no problem

Good News. So far with V1.121 I can not duplicate the scaling issue when light mapping a model that has scaling
applied to bones. I am not sure what changed since the previous version. If the scaling issue reappears
I will email you with details to try and reproduce it. Can anyone else reproduce it with V1.121?

There is still the problem with light mapping a model with overlapping UV coordinates in V1.121.
Does the light mapper use a second UV layer? This can be duplicated by just light mapping the supply crate
model. I posted a screen shot in post above.

I was not aware of a second UV layer in the supply crate geometry. Does anyone have the skills to drill into this X model and let me know if there is a second UV layer on the geometry or a second polygon overlapping the primary ones which could also cause the issue observed. Thanks all!

There shouldn't be a physical second uv mesh layer in the geometry of the .x model. As I understand it with my limited knowledge it is a 'phantom' uv layer created which overlays the original and can have a totally different uv layout. This can be seen in the lightmap itself which is obviously an auto unwrap and totally different from the models original uv layout.

If you look in the lightmaps in the testmap folder you can see this and the .dbo files which accompany these. i can only assume these are the terrain lightmaps and the supply crate with wooden crate (long)



This is the unwrap for the supply crate.


Now, if you open these .dbo files in a modeling app you wont see any mesh but they do have a face count, if you add a tessellate or turbosmooth modifier they will increase the face count so though they don't have a physical presence and appear as phantom they do add to poly count. You would only need one unwrap per model so if you had a dozen of the same only one model with several different lightmaps to do the job, all the same you shouldn't be seenig multiple objects for the terrain 'blocks', at least I assume that is what some of these objects are in the folder though they might be LOD meshes from the models which shoudn't be created since you only require the highest LOD to lightmap. I can only guess with this one

This is something I discovered when I was reading about a bug in the autodesk .fbx converter back in 2013. In some blog they were discussing this bug and how they could convert to .dae then select faces to apply textures and effects on different 'layers'. they believed it was a single mesh. A plane with two faces, they were applying a material with three layers to the mesh and on converting to dae from fbx were believing this model had only two poly's but you could select three material layers.
Of course I had to dig into it and found that it actually had six faces in the model but when selecting sub object it appeared to be one single mesh. When I applied a turbosmooth modifier to it all the faces split apart and I could select the sub object faces. There were in fact three planes in the model.
I used this in the skyspheres I have been creating where I discovered you could create these meshes physically and have them occupy the same space for effects which overlay each other.

The reason I go into all the above is because I believe in the same way as you can create non physical vertex geometry in a shader to apply textures and effects to (this can be seen in the skyscroll shader where a plane is created) I reckon the same sort process is used in lightmapping.

I have imported one of the dbo in the lightmap folder and it is difficult to tell which is which but the one I did import had over 9000 faces even though it doesn't appear in app.

I have no idea why some models aren't unwrapping properly in the lightmapper but it isn't because of overlapping uv's in the .x. Just about all the stock models have overlapping uv's and most lightmap just fine. It may be something simple like model parts all being separate on export or maybe some other reason, I wouldn't have a clue at this point as they aren't my models and I have no idea what app they were created in

I will all the same try importing the supply crate and take a closer look at it, I have found sometimes that little bugs can be fixed by importing and simply exporting again to fix things. Some exports can be radically different in export data contained in the model file, as seen with fbx having different data over different versions in the export module which some engines get confused by.

It is kind of strange since I have found that with at least one test lightmapping there were no .dbo objects and only the maps in it, most of the tests I have done produce these 'phantom' models but on one occasion it didn't. So maybe this will help give you a clue as to what is going wrong.

edit*
Took a look at the supply crate model, it has three mesh layers but I cant select the single sub object meshes which I assume may be LOD levels, maybe this model was collapsed to single mesh before export in error, when you do a lot of models you sometimes make mistakes. As said I cant select these meshes as single objects so cant fix it, the original author should have files to go back to and try exporting it again.