exporter/Blender 2.5/2.6 series

[Yggdrasil]

Sounds quite hacky. Isn't there a better way?

I mean you magically set it from invisible to fully opaque. Invisible objects are probably useless, but still...

[Omega]

I mean you magically set it from invisible to fully opaque. Invisible objects are probably useless, but still...

Are they really useless? I feel they could be used to help the selection of units. For example, the Undead faction used a "ghost" unit that was pretty much just particle effects. The model as I remember it was a small cube, which made it difficult to select the unit. A larger, invisible cube would have worked better. Of course, we could still mimic invisibility with a transparent texture, but setting the model transparent could remove the need for a texture entirely.

[titi]

What Omega says is right, selection is a reason why fully transparent object might be good. The problem is that exporting invisible object is mainly done by accident.
For example if you want to see something like a tree with all transparent parts in blender you have to set full transparency on the object, just to see the transparency effect of the texture. And if you later export, you see nothing in the 3gd-viewer.

Its not the format or exporters fault, its more something not so good in blender itself. To help out with this I decided to add this. You can still get a transparent object by setting the transparency to 0.00001 or so ......

Maybe its a good idea to add an explicit switch "fully transparent" to the exporter options in blender. By this you can be sure to not export fully transparent by accident, but we keep the option to make it fully transparent if it was the modders intention.

[Yggdrasil]

Mhmm, yeah, i think i'll add an option 'fully opaque' which always sets the opacity of the mesh to 1.0 on export, ignoring what's set in materials.

[Yggdrasil]

Code: [Select]

added new option 'fully opaque' to blender addon

This new option is a mesh property located in the G3D properties panel. If
enabled it sets the opacity of the mesh to 1.0, ignoring what's set as alpha in
materials which is normally used for the opacity. This allows the modder to set
alpha in materials to 0 and see the alpha effects of the texture in the 3D view
of blender.

The link has changed:
http://sourceforge.net/p/glestae/glestae/ci/master/tree/source/glexemel/g3d_support.py?format=raw
(Right-click 'Save As', name it g3d_support.py, in blender: File->User Preferences -> Addons -> Install Addon (bottom), pick the downloaded file, enable it)

[titi]

uh I missed this when you wrote it.
But thanks a lot, I will try it when I am at home.

[titi]

atze told me about a strange behaviour of the g3d importer. the last frame always looked like the first frame and the first frame was missing.

I looked at the importers code and found out that the reason is line 427:   

Code: [Select]

for i in range(1,header.framecount-1):
If you remove the "-1" all works as expected. But I am not too sure if there are cases that make trouble which might be the reason this was once added. Can you comment on this Yggdrasil ?

[titi]

I think Ifound a serious problem with the current G3D exporter resulting in g3ds with too many Vertices. Somehow many vertices are duplictaed when exporting. Looking at the code of the exporter this has something to do with textures and UV-Coordinates and duplicating vertices. The problem is it duplicates much too often!  Blender and the g3d viewer typically show a very different number of vertices for a model. You can see the problem too if you reimport the g3d into blender.. If you do so you can remove double vertices from the model and there are many of them!

In the code ( g3d_support.py ) this is around line 630 and line 650.
Is this a problem of the g3d exporter or is this a general problem of the g3d exporter?

More vertices are for sure not a good idea regarding performance :-/

Here is a model for testing: http://titi.megaglest.org/bugs/brainbug/

[will]

Do these vertices get removed if you optimise in silnarm's g3d_hack?

I'm just guessing but perhaps towsided meshes are why?

[titi]

Me and willvarfar looked at it again. In the exporter the vertices are somehow duplicated. Only thing not 100% clear now is, is it right or wrong?

Current state is: I commented out all this duplication thing and  I get a ( for me ) proper looking model.
But following the logic ( in the code and what willvarfar told me ) there is a need to duplicate vertices if they have different texture coordinates. Looking at the UV Layout of my model this is maybe needed.
But following this logic, why do i get  proper ( and smaller ) g3d when I get I export without maybe needed duplication ?

all needed files are here:
http://titi.megaglest.org/bugs/brainbug/

brainbug6.g3d is the original export with current exporter
brainbug7.g3d was exported with the vertice duplication commented out ( and I don't see a problem )

blender states the model has 791 faces
brainbug6.g3d has 941 vertices ( according to g3d viewer )
brainbug7.g3d has 791 faces as blender states it and I don't see any problems with it.

[titi]

OK after thinking a bit about it here are more tests:

here is the model http://titi.megaglest.org/g3dtest/g3dtest.blend ( texture is here: http://titi.megaglest.org/g3dtest/g3dtest.png )
looking like this in blender:

(click to show/hide)

Blender states that it has 8 Verts.

Exporting with all vertice duplication switched off results in something broken:
http://titi.megaglest.org/g3dtest/g3dtest_org.g3d
Looks broken like this in the G3dViewer:

(click to show/hide)

This has 8 vertices

Exporting with current g3dexporter without any modification results in:
http://titi.megaglest.org/g3dtest/g3dtest_org.g3d
This looks like this in the G3dViewer:

(click to show/hide)

This has 32 vertices

After removing dublicate vertices with G3dHack:
http://titi.megaglest.org/g3dtest/g3dtest_g3dhack.g3d
This looks like this in the G3dViewer:

(click to show/hide)

This has 24 vertices.

( all data can be found here: http://titi.megaglest.org/g3dtest/ )

Update: The big differences in the number  displayed by blender and by g3dviewer is definitly a different way to count the vertices so things are less worse than I first thought. It rests the duplicates found by g3dhack.

[will]

Intriguing, and excellent test files.  I will poke around them on Monday.  I ought to be able to work out what is duplicated, at least.  The why may need learning the blender api to understand what meshes it gives us.

Its an annoying bug, and easy to become obsessed with solving, but its not a crash bug

[Yggdrasil]

The import of the animation was just a hack. The first thing which seemed to work.

There's code missing after the loop to handle the last shapekey in a special way. If extending the loop works too, then one can probably make the code even more simple.

I thought i fixed the problems with duplication but there's another bug. When a new vertex is created, it's not checked if it was created before. That's why you get unnecessary duplicates which are the exact same vertex-texcoord-pairs (g3dhack removes them). I'll try to fix it tomorrow or so.

The reason for duplication is simple a limitation in the g3d format (actually opengl likes it this way too): Every vertex can only have one texcoord. If there are more texcoords, you have to duplicate the vertex. Blender allows multiple attributes per vertex to make editing easier.

[titi]

hi! About the importer I just want to mention that it works completly ok for atze with this little change I suggested!  He shrinked a whole techtree manually in blender and everything worked for him . Just import/shrink/export .
I am not sure I completely understand what you wrote, but we don't need the last shape key to be the first one. In the the rare cases we would need it we can set it manually.

[Yggdrasil]

This should be fixed now. As always, testing is welcome as i don't have enough models nor blender knowledge to really test it.

Here the link again:
http://sourceforge.net/p/glestae/glestae/ci/master/tree/source/glexemel/g3d_support.py?format=raw
(Right-click 'Save As', name it g3d_support.py, in blender: File->User Preferences -> Addons -> Install Addon (bottom), pick the downloaded file, enable it)

[titi]

This is a lot better  . I need to test some more and atze should test import again, as he knows best whats going on there. Atzes english is not the best, can he write in german too ?

update:
Just to give you an idea: one of my current models has 941 vertices with old exporter and 845 vertices with new one !, this is very good news ( for bad gfx cards ).

[Yggdrasil]

I have no problem with german. The importer is fixed like you did it. It seems to be the easiest way. Nothing else was changed in the importer. So if that worked for him before, he doesn't need to recheck everything.

It's even more important if you know that the vertex is duplicated with the corresponding normal and for every frame... For models with many frames this gets nasty.

[titi]

Is it possible to remove the double vertices after you imported automatically ?

I had a quick look at some blender code and I think this does it if you do it for all imported objects:

Code: [Select]

bpy.ops.object.mode_set(mode='EDIT')
bpy.ops.mesh.remove_doubles()
bpy.ops.object.mode_set(mode='OBJECT')


[Yggdrasil]

It's sadly not that simple. These operators only work in certain contexts which is not well documented. I can't use these operators inside an importer. I used a bmesh operator instead. You have to use at least Blender 2.65 from now on, better use the latest version.

Fun fact: Importing and then exporting an archmage model gives less vertices than the original. I'm not sure if the model was changed since vanilla glest. But maybe the old 3DS exporter produces unnecessary duplicates too. Or removing doubles in blender does more stuff than it should...

[titi]

Its exactly like you say, the original 3ds exporter had trouble with unaccecary duplicating vertices. Thanks a lot for your help! 
( and btw these are the nice new monsters I exported with your exporter

(click to show/hide)

[titi]

Trouble with the normals:

  bad news i have trouble with the current exporter. Somehow something must be wrong with the normals of the models, or its not wrong but incompatible with the current MegaGlest code. Problem is when you move a unit around the lighting is not calculated the right way. I have no clue what happens there.
Here is a G3d and its textures. It's showing a spider under a big web. http://titi.megaglest.org/g3dtest/spider  ( and it's blender file )
replace one units g3ds in MegaGlests original data or betterin a mod with this model and look at it in the game. When you start the game all is fine, but when you move the unit around, strange things happen with the lighting of the web. ( you can even try without net texture to see it more obvious ). If you turn the unit facing to the left, the lighted part is somehow nearly in the ground  on the opposite side.
And yes I double checked it, the normals of the models are ok!

Here are some screenshots showing the problem. If you look closely the spider shows the same problem ( its back is always lighted in strange ways )

(click to show/hide)

(click to show/hide)

Update:  More Infos about the normals:
This is what you get when you display the normals in G3DViewer:
 

(click to show/hide)

This is how they originallly looked like in blender ( ignore the texture )
 

(click to show/hide)

[Yggdrasil]

A wild guess: Disable the rotation on export and do it manually. Maybe i forgot to rotate the normals. I have a look at the code this evening.

[titi]

I don't really get what you mean with the rotation :-/. There is nothing rotated when exporting. I better wait until you have time to look at it. Then I will export all again.

[Yggdrasil]

I meant the exporter option "rotate to glest orientation" which is checked by default.

The normals weren't rotated. I'm surprised nobody noticed it earlier. I hope it's fixed now.

Here the link again:
http://sourceforge.net/p/glestae/glestae/ci/master/tree/source/glexemel/g3d_support.py?format=raw
(Right-click 'Save As', name it g3d_support.py, in blender: File->User Preferences -> Addons -> Install Addon (bottom), pick the downloaded file, enable it)

[Coldfusionstorm]

Just set blenders export option to start up with glest orientaion

I was not aware the script/addon had this feature.

Also Thanks a bunch Yggdrasil, This streamlines the process ALOT.