512x512 terrain textures...

#21 It looks as though you should just be able to change those values in blender.cc and they'll carry over to blender_asm.asm. Might be worth a shot.

#22 Mmmmmm, something right up my alley. I'll take a look at the assembler and see if I can finger something out.

#23 Did something get done here?
I tried to add 512x512 textures today and the familiar stripes came up everywhere and it looked sh*t.

Would be really cool if there was an easy way to make it work.

#24 TSE supports arbitrary terrain texture sizes. Of course, finding the memory to store them in is your problem - even with 256x256 textures it's easy to burn through 128 megs of texture ram.

#25 Ben

I won't have the money to invest in TSE I'm afraid. :/
I have tried to add 512x512 textures but they get pixelated at longer distances and black stripes at medium distance.

You think this would be any hard to fix?
If not, then I might look into it.

#26 I'm going to dig into this myself.

Probably going to end up lost but I'll post anything that I find out here.

#27 I have got 512x512 textures onto the Terrain now, but the performance hit is horrible.

Could it be something with mipmapping?

#28 The C blender is not really fast, and the fact is that 512x512 is gonna eat video memory like mad. I would see what your vram usage is like, perhaps using the nvperfhud (if you have an nvidia card). On the experiments I ran with TSE, using 256x256 textures could easily saturate a 128meg card's memory, so it seems likely to assume that 512x512 might only be feasible on a 1gigabyte card. ;)

#29 One thing is that w/o the modifications, the 256x256 terrain textures are blended into a 16 bit (5551 format) 128x128 texture. By bumping up the destination texture to 256x256 and possibly 32 bit would probably help a lot.

#30 I've done a lot of work with the blender code and can give a few pointers. This info is based off of 1.1.2, but probably still holds true, also I'm doing this off of the top of my head and can check this out at home later if you'd like.

The macros that define the source, destination, and lightmap sizes only play well with the C++ blender; often changes will crash the asm blender.

Bumping up the source texture size doesn't do anything, although the source texture can be 512 the blender is going to scale it down (by only using every other texel row/column).

Bumping up the destination texture size doesn't do anything, the coverage ratio of source to destination textures at the highest detail level is 1:4 (that's a 256x256 texture going into 4 128x128 textures, or all 4 128x128 pieces of the 256x256 texture going into their own destination texture). When the destination size is moved to 256 the ratio stays the same, so although the textures take up more memory 128x128 source pieces are copied into the 256 texture, this clearly does nothing.

The only way to really change the detail is to up the source and destination textures. Not only did this crash the C++ blender, but when it does run the C++ code is _SLOW_.

Personally I ripped out blender entirely, but maybe the info I have will help you find a solution. Let me know if this helps!

-John.

#31 Ben Garney: Yes, all that is of course true but;

Terrain. As far as I know you won't use more than 6-8 different textures (and in the enviorment I'm working that's more than we need anyway).

A 16MB card could handle that.. with no compression and nothing else in the memory, no? Doesn't Torque handle OpenGL compression? I thought so.. doesn't that compress textures a slight bit when in memory? :) Many questions.

And if it's so unpractical, why do you implent it in TSE? ;)
Well, my point is that it depends on the game. We won't need many textures for terrain, AND in the "future" a 128MB card will be standard.

Chris: This was unknown to me. :/ "without the modification" - can you clarify that a bit? Which one? The originally posted one?
That could be relevant, do you know how to proceed?

John Kabus: This was my experience too I believe.

Some modifications made the ASM blender crash upon loading the mission, and when disabled the game runs, although VERY slowly. Or well, it runs good but when I make fast turns and move alot it freezes up for maybe 500ms and then flows again.

I guess that's the C++ blender at work.
Well, with all said now here that was unknown to me I'm very confused :P

Any info is of course helpful, anything on how to make 256x256 truly work, just to step up the detail a bit - would also be helpful, just anything. A few pointers :)

Would be cool to put this as a resource if we get something working, I think many would want it.

#32 The terrain 'system' caches a pre-blended copy of every visible terrain tile (real-time blending is prohibitively expensive). The actual number of textures can be hundreds.

#33 Come on, that's still not what this is about. :)

#34 What are you talking about?

#35 I thought you were talking about that textures would clog the GPU memory? :P Ben spoke about it a few posts ago.

#36 Oh... I was just letting you know why Ben posted that info.

I have a 64M card and 256x256 destination textures are fine, however getting the C++ blender to work is the trick.

#37 Yeah. Does not seem I have the knowledge to fix it either way so :/

#38 On fast ps2.0/3.0 hardware you could probably do away with the blending system. It's an optimization I'm looking at doing sometime, once I get the terrain code refactored.

#39 Ok, thanks for the information Ben.

One follow-question then that I haven't seen answered;

Can I use TSE without the Shaders? If the code is more clean and supports other stuff than just the shaders, I would like to try and pass the shaders but still use the package.

Is this possible?

#40 You get the source, do what you will with it.