problems with colors

[titi]

Hi, I'm working on a new tileset ( I try something with photos ).
I have a problem with the brightness of the colors.
I have the same bushes/trees in different places. Sometimes they are dark ( like in a shadow) sometimes they are light.
Can anyone explain it to me?

The same bushes look different ( but should not )


 trees left and right look different ( but should not ) left one is completly dark and the right one is shining very bright ( the new one with the leaves )

[martiño]

I think it might be a problem with the lighting normals, i think you might have to dissociate the vertexes in the flat polygons. But I'm not sure maybe an artist would be of more help.

[wciow]

I also have this problem with the tropical tileset. I'm not really sure either but maybe it is because the engine cannot properly decide how to light flat planes  and gets confused, so some models are lit entirely as front face and some as back face?

Btw, your tileset looks very nice

[titi]

I hope weedkiller can help us here .....

Sorry, thats not really a tileset yet! I'm only trying something. I'm thinking of generated trees with prepared photos I took. This will hopefully result in a fast creation of good looking trees! All newer games have these pre-generated trees and by this lots of good looking plants.

[wciow]

Are you using the Lsystem script for Blender? I've never tried it but its a tree generating script.

http://jmsoler.free.fr/util/blenderfile ... system.htm

The preferred system for generating forests is called Speedtree ( http://www.speedtree.com/ ) but its aimed more at first person games I think. Also it probably wouldn't be implementable in Glest without a major code overhaul and finally its commercial software so a BIG no-no for Glest.

[titi]

Yes its the lsystem ( and a modification of it ) . I'm at work here so I don't know the correct name/url. What I found is all free and calculates the trees in blender. They can be exported(hopefully) like normal objects then.

[weedkiller]

I dont know much about glest tileset-stuff...
If its a problem with vertex and normals, you can try viewing the modell(g3d) in the g3d-viewer but without texture; then you should see if there are hard edges or wrong shaded planes.

Or give me the blend and i will have a look; but i think martino's suggestion is the only problem i can think up here too.

But i hered something stange about alphamaps blending iin glest sometimes ago; was there something that dark textures dont work good with it? Maye we should try this too.

The biggest problems seems to accure with the thin bush. That can be antialasingproblem; because you have turned antialasing off it dosnt smooth the bright pixel next to dark ones... I think this can only occure if geometry is lower than one pixel, but i have no real knowledge about that...

[titi]

ok , I will upload it this evening.

( Look at the second picture, the tree on the left is completely dark and the one on the right is shining bright, thats what I mean )

[titi]

here it is:

www.titusgames.de/viking/notviking/baum2/baum2.blend
www.titusgames.de/viking/notviking/baum2/baum2.tga

[weedkiller]

Hi back
unfortunately there still seems something wrong with blender exporter/glexempel.

The problem titi recognised was because the g3d has wrong normals in it. Some normals are right as they originally were in blender but especially the planes that intersect have wrong normals:


I dont know if glexempel recalculates normals and makes errors here, or if blenders exportscript writes wrong normals/ writes in wrong order...

I will need further testings to be sure about it. I even had problems with glexempel converting a glest_treeg3d into xml because he only gave a empty file, so perhaps i made a mistake in usage of it cause i use glexempel on wine.

[weedkiller]

He good news, kindof:
The error was because of blownup Blenderfilestructure; titi, you used a script right? So something was wrong with the blend so the exportscript went mad. OK, this can often happen, perhaps if you use undo and redo often or copy your model and delet old one... If you have it, export your geometry as obj  and import it again (perhaps append works too)... then even our script is capable of writing the right normals  .
Ok perhaps we can improve our script based on the obj exporter as it seems to work better but thats another topic.

On the other had the tree still looks funny (in g3d viewer); I think we have only one point light in the g3d-viewer; so even a box can look odd, perhaps GAE can have a look on this or answer my question how the lightning works.


Ok, this is not really a good idea, just follow it if the tree still doesnt look good in glest.

[titi]

No this model wasn't made with a script. This was only a test because the script will work a bit similar.

It was made by hand, but I made a lot of bad copy and paste things. First I created one plane. Then I copied it very often as an object.
This was wrong in my opinion and  so I joined all the leaf-planes into one object. Probabaly this joining was a bit confusing ....

[titi]

OK I found something. There are two problems:

1. my model had very strange normals ( as weedkiller said ) but this is not a problem of the exportscript I think. It was my fault
2. Glest has a problem with shadow calculation of planes. Planes are shown doublesided in glest, but the colorcalculation is only based on the normals.
So if you have a plane with the normal towards the sun, its shown light ( from both sides! ) when the "sun" turns araound and the normal suddenly is in a wrong position to the sun, the panel turns darker(again on both sides) . Thats what is a bit strange. So textures are shown doublesided, but shadow/lighting calculation is made singlesided. ( thats what I think )

So here is my way how to fix it:

Make all planes with a normal and all normals are showing to the top/(or inner side of the bush).
Before exporting to glest mark all the planes and duplicate them. Then move the copied planes a little bit downwards.
Then flip their normals. This will give normals in the other direction ( downwards or outer side of the bush ). Now you have a correct lighted object in glest and the leafs are looking a bit more plastic.

[weedkiller]

good idea titi that sounds like the best solution

one question: does the doublesidedbutton in blender work for you? for me it changes transparenzy/teamcolor but not doublerender. I can only achieve it by editing the xml but i must change the "customcolor"boolean for doublesided; the twosided affects teamcolor/not=transparenz...

I just wonder if that is due of my bad glexempel copy or something.

[titi]

?? thats possible to say glest to render only one side in the xml-file?
If this is the case we should definitly look for a different switch for the teamcolor. Something annoying I also forget often is to switch down the frame numbers to 1. Proabably there is a solution too ( for example endfarme 255 and startframe 1 will result in 1 frame export  or something like this.)

[weedkiller]

i think we talk of different xml files here  :roll: : if i separate the planes i get it shaded wich hard edges, so no wonder that it looked bad. Only problem: it would be easier if the exporter would create such normals if you change modelparts to solid in blender. But thats not easy since normals in blender are always stored smooth and not solid, its only a displaying option.

[titi]

cool!

I never saw the default settings... it's so easy ... I am so dumb!  

Thats something for the wiki to help other dump people with this problem.....

[weedkiller]

Hi again,
i found a new trick which other might find usefull:
Its possible to edit normals within blender so that they are solid/smoothed even in the export:

As explanation whats this is about:
Imagine the cube i posted. The normals decide if the edges are visible hard shaded or smooth so you cannot notice them in best case.
For this cube smoothing looks weird because its not possible that the edges cannot be seen; its a corner of 90° and so the attempt to make it invisible leads to bad shading on the planes...

In blender you can easily adjust to which corner angle it shell try to smooth the edges: You must use the modifier "edge split" on the mesh. Adjust the angle-value till the modell looks good to you (use viewingmode "solid"). You will notice that normaldata is really changed: If you display the normels you will see how they move when you change the angle-value.

Ok, if its not clear what i whanted to tell, just ask again.