IWTE - Vegetation editing

[makanyane]

This looks like a lot of fun to fiddle with...

that's one way of describing it...

So, when looking at the temperate_deciduous_forest climate in the SGT_To_G-Hardness table and it says for FERTILE_LOW "SHALE" "QUAL_VERY_LOW" and I look these up in the G-Hardness_To_BGT table where it says "gravel", then "gravel" will be the "main" BGT in the fertile_low SGT? And the hs fade-in, hs median, hs fade-out, ... then control how other BGTS appear in that SGT? Do you know what each of these hs fade-in/out/median, gs fade-in/out/... do?
edit: after heaving a first read through Muizers guide that seems to be kind of covered there, wow getting into all this stuff will take a while...

if you ever do understand Muizer's guide fully can you come back and explain it to me? Assume you've got this bit now but the bits starting 'h' are height related, and the bits starting 'g' are ground type related. But the control of which bit it looks up on that other table i.e. if it's mainly 'gravel' or not, also depends on heights/slope - it kind of centres you on the indicated bit in theory first, then according to other stuff about the map, like if it's shoreline, or high-ground then it'll tend off towards either the left or right of the table.

Am still trying to find those textures...

[makanyane]

Found textures; should be here; https://www.dropbox.com/s/uqan33i3rt...named.rar?dl=0
but dropbox seems to have gone a bit funny on links, let me know if you have trouble getting to that
if you get them basically switch either their names so they come up instead of the climate's existing ones or more reliably edit the db so that the relevant battlefield groundtype uses the texture of same name.

[makanyane]

Re: the tree sprites, we've been a bit tied up but are back to looking at it - main problem with your tall trees going dark is to do with the background colour IWTE selects which then gets merged with the 'screen shot' of the tree model as it gets reduced down. WD has I think now got a better way of selecting that colour.

Meanwhile we're also having a little look at the normal and alpha shape of the _diff.texture too, to see if that can get improved a bit.

Did sort of know this before, but couldn't find my notes so re-tested it, and posting here so I don't lose it again... So; the transparency/alpha channel on the sprite diff texture doesn't actually do true transparency, i.e. you never actually get a bit of sprite you can see through. It only works as an on/off switch, so any pixel that has an alpha channel grey value of RGB 149,149,149 or lighter shows up in game. Any pixel that has a grey value of 148,148,148 or darker doesn't appear at all. Some pics to show the test.


I've narrowed down the point where it switches, and painted the various sprite sections with the stated alpha values. The 148&9 square has a few 'holes' of 148 value.
The 150 square has a bit of 255 pure white alpha across it.


shows the 148 bits appearing as gaps.


the 150 square doesn't show any difference between 150 alpha value and the 255 bit.


...and mip-maps aren't actually used by the sprite - even if the .dds/textures were created with them. I tried painting the expanded mip-map section a different colour and it doesn't turn up at all...

[wilddog]

New version has just been released. version 16_07_A.

xHolyCrusader - I think this should of addressed most of the issues you raised. I don't have a converter for converting TGA back to dds directly. Would need to see if I can build in a link via a conversion routine. There are links already though for directory conversion of dds files to textures and vice versa. They were in the painter process access via the 'fileypes menu in the top left. The buttons in the main process were just legacy code that I'd left in.
Process should also always create an IWTE save directory from wherever you run the executable (previously caused a crash if it didn't exist).

[xHolyCrusader]

Finally had some time to test the new version, I really like the updates/improvements on the sprite generation process they look a lot better now. Especially on the winter version of that beech tree which uses a lot of alpha channel the switch between model and sprite is so much smoother now.

[MightyPotato]

I keep getting the following error message ever single time I try and read a .vege_model I created:

Request vege_model file..
veg model file read
QGLContext::bindTexture(): DDS image size is not valid.
failed - no size
Traceback (most recent call last):
  File "<string>", line 12564, in Clickedviewvegmodelbutton
TypeError: 'QImage' object is not iterable

It seems to be a problem with the texture, as everything works fine when I don't add it to the model comments, but its strange because it is a DXT5 texture and its size is 512x512, so it should work fine... Here is the model if you want to have a look

larch.zip

[xHolyCrusader]

Had a quick look at the file and it indeed seems to be the texture, when running it through photoshop and exporting as dds again with these settings everything works fine. In case you are using gimp can you show me a screenshot of what export options you use/have available please?

[MightyPotato]

I tried that in Photoshop but it seems to have refused again! I also tried with another tree, and i didn't work either, and neither did changing the .texture from DXT5 to DXT1.

Btw just for info the tree comes from RSIII Rome mod, if it helps anything.

[MightyPotato]

Nah, I don't understand this. I tried taking a .texture that works, opening it in DXTBMP, converting it to .dds (I tried DXT1 and DXT5) and then converting it back to .texture (I tried DXT1, DXT5 and 32bit) and it doesn't work either, so maybe my DXTBMP conversion system from .dds to .texture is not working correctly... Does anyone know how to fix this?

[xHolyCrusader]

Nah, I don't understand this. I tried taking a .texture that works, opening it in DXTBMP, converting it to .dds (I tried DXT1 and DXT5) and then converting it back to .texture (I tried DXT1, DXT5 and 32bit) and it doesn't work either, so maybe my DXTBMP conversion system from .dds to .texture is not working correctly... Does anyone know how to fix this?

Have you tried the inbuilt .dds/.texture conversion of the IWTE yet? What about alpacas converter?

[MightyPotato]

I am trying alpaca's converter right now, and I'll try the IWTE functionality after. I'll keep you updated

Update: It worked with the IWTE tool and alpaca's (which is a lot easier to use as it can convert multiple textures at once: rather good when you have 126 to do)!

[makanyane]

I can't quite figure out what is up with that original texture - I did notice that the .dds produced from it doesn't 'preview' in windows explorer either (I've got an add-on which does show a preview for other .dds files) - so it's not just IWTE that doesn't like it (wd will try and have a look later but he's between python versions currently

anyway glad the re-saving via photoshop works

later versions of IWTE will bulk-convert dds/textures if you use the "texture/dds conversion" drop down under the "file type" tab in the top left of the window and select one of the "directory" options - converting via that will stick the new file in /IWTEsave folder though so you'll need to move them.

[MightyPotato]

Nice! Will it do the same for the vegetation models?

[MightyPotato]

Helloo, back with another problem: everything works beautifully except for a few trees. Although their sprites look fine and their model preview in Milkshape and IWTE looks fine, the textures on these trees mess-up when I get up close in gme (meaning that they are there, but not where they should be, just strangely mapped on the model's surface). How does one fix this?

[makanyane]

Helloo, back with another problem: everything works beautifully except for a few trees. Although their sprites look fine and their model preview in Milkshape and IWTE looks fine, the textures on these trees mess-up when I get up close in gme (meaning that they are there, but not where they should be, just strangely mapped on the model's surface). How does one fix this?

oops missed this...

is your texture an odd (different to vanilla size) - or does the mapping extend off the edge of the texture? There's a bug with some of the large_stones in one of the vanilla climates that shows that although things may look Ok in ms3d etc - if you go outside the edge of the standard texture size you end up picking up stuff from the next model! Basically you can't 'lap' stuff around a texture as you can in milkshape, it has to actually fit on the size shown in the texture viewer.

[MightyPotato]

Sorry for the (very) late answer, my problem was with the trees. I don't have pictures but it looked like the whole texture painted itself only on every individual face of the model, making it look really messed up. It however looked good in the IWTE...

[Sirlion]

Hello. I have a problem generating a new vege_sprite. I have converted the models successfully from ms3D to vege_model, and put the textures in the /vegetation/textures/ folder, both .texture and .tga formats. However the IWTE program tells me this when I try to create a sprite:

Request vege_model file..
veg model file read
QGLContext::bindTexture(): DDS image size is not valid.
width = 0
height = 0
val = 1
failed - no size
Traceback (most recent call last):
File "<string>", line 12307, in Clickedcreatespritebutton
TypeError: 'QImage' object is not iterable

I dont know why it calls for a DDS since it's .tga, regular 512x512 texture.
Any advice?

EDIT ok didnt read above. I will try the converters provided.

[Sirlion]

Allright, that one worked out in the end. Now I have another question... I'm sure its easy to solve but I cant figure it out.

I have made a separate grass texture and separate winter models and sprites for the Mediterranean Winter climate. However, the Winter season shows only Summer grass and models, even tho I've pointed the game in the right places.
I read in the grass tutorial that grass appearing in winter is a good thing, however the game wont pick up the actual winter variant no matter what. And even more strangely, it wont even consider my winter models, which I have placed correctly in the right folders; my Winter Mediterranean climate looks like this



These are regular custom models with custom textures. Everything works correctly as long as I place it in the Summer season, but nothing will be loaded from the Winter season. Why is that? Is there a solution somewhere? Do I have to change climate entirely?

[makanyane]

Check your descr_climates.txt to have 'winter' the climate has to have "winter" in its entry like

climate steppe
{
colour 237 28 36
heat 1
winter

strategy summer sparse_tree birch_a.cas 1

Mediterranean doesn't by default

[Sirlion]

Check your descr_climates.txt to have 'winter' the climate has to have "winter" in its entry like


Mediterranean doesn't by default

Thanks, I have added the winter condition to descr_climates, however nothing has changed. The game looks for my winter textures strictly for the terrain, but it keeps adding all of the summer grass and model variants disregarding any winter entry