Turtle Isle (age problems)

[dendwaler]

Hi all,
I have serious troubles with my age.
It seems to be related to the tranparacies issues Tweek has.
Given is an example screenshot of 2 situations.

I have a transparency of a blue lilyflower against a waveset.
All is normal
The second pink flower against a cactus is with a usual background at that time.


After that i made a copy (shift D) of the lilyflower)
thats the only change i made !

After the export the pink flower seems to have a part of the waveset around its edges.
Both flowers does not share any materials.
rendering in both examples is late. (forced within a alcscript)
I have done everything I can for days, but cannot solve this.

Any suggestions or Ideas?

[dendwaler]

I solved it finally,
After duplicating the lily I inserted a new piece of alcscript for the late rendering.

But with inserting i seem to have exidentally inserted a "space" aswell, so the next lines of the script where not executed anymore.

Here is a pic of the result

[ddb174]

It *does* look like the sort of place a turtle would love :D

[dendwaler]

Does anyone know how big the "District_mainRoom.prp" and the "District_Textures.prp" may grow?
What is an advised maximum?
When are you forced to split the age up in visible regions? (even when you don't want to.)
How many regions can you have?
Is a max prp size video card depending? or videocard memory depending, or mainframe memory depending?
I have no idea.
Or isn't there a limit at all?

I ask this because in my age the two prp files are already around 50Mb each.
When I continue building in it, this figure could easily double.
At this moment it run's well on my pc, but on an older system? ..i don't know.

any comments are appreciated.

[diafero]

I don't know the file sizes at heart, but have a look at some of the big ages out there - Takla Ma'kan, Janga, Tvel - and see how large their files are. Janga and Takla Ma'Kan are quite old though, I don't know if today's PyPRP versions have some improved compression mechanism to reduce file size.
However, you should be more worried about the number of vertices and the number of really big textures (bigger than, say, 256x256) - they are better suited to estimated how heavy your age is.

[dendwaler]

thx diafero.

the number of vertices is about 215000 over 162 objects.
many decals are joined into 1 object to share its textures.

About the size of the textures.(256*256 is your advice)
Is it really the size in pixels or is it the size in bytes what matters?
if it is in pixels i can still reduce it. lots are 512
In bytes however i think that will be not significant, but i can try.
I do not have many large textures, i used mainly jpeg and reduced the quality of it to 70%
That gives a great reduce in byte size without losing much detail.
I can see the difference of quality reducing in the "gimp" but can not see difference in the gameengine.
The biggest texture space consumer is vertex painting.
A great and easy technik but i did not split up the age in smaller parts.
now i have 7 layers over the isle as a whole, which is waste of texturing of about 60% i guess.
And i still need a next layer as a lightmap.

The lightmap for me is a problem in itself.
It works , but i want to use it for an outside enviroment to get proper shadowing.
However, also the not shadowed parts turn out to get much darker.
To dark for my taste, but not solved yet.
I will try to edit the lightmap in the gimp to lighten it,
(sort of bias)

[kaelisebonrai]

Pixel size is the important thing here, rather than Byte size. I don't know Plasma as well as some others, but, I'd personally say 512*512 should be ok, I'd hope it would be, at least, but I could be wrong in my thoughts on the limits of this engine.

I'd recommend using .png compression instead of .jpg compression, to be honest, PNG is lossless, but still compresses pretty nicely.

[boblishman]

All of your textures are converted by PyPrp to DTX format at export, so do not think you are saving any filesize by using jpegs ...
look in the "tex_cache" folder of your age (in the dat folder) ... you will see that your exported (and converted) textures have "common" sizes ... these depend ONLY on the pixel size and whether they use Alpha or not ... as kaelisebonrai says, png is probably the best format to work in.

Check that textures that do not need an alpha (transparancy) layer do NOT have the "Use Alpha" button checked in Blender (otherwise Prp will export it as a DTX5 - which is a larger file size - instead of DTX1 (smaller)... You can see which format your textures are converted to during the (first) export of your textures in the Blender console window...
.... it's worth watching that window at export ... many times I have spotted textures being exported as DTX5 that did not need to be (because I had forgotton to uncheck the "Use Alpha" button - which is "on" by default ... )

Remember, that if you change any texture's atributes but retain its original name that you will have to delete it from your texture cache - and "reload" into Blender - before exporting (or PyPrp will continue to use the "old" version from the text_cache)

The real "trick" is to re-use materials & textures (or parts of them) over and over again ... in such a way that the player does not notice ... (Cyan does this all the time) ... and, as diafero says, you can try reducing some of your 512 x 512 textures to 256 x 256 ... you might be surprised at how little difference there is in game (depending on the object's position releative to the avatar and camera).

[Jojon]

What Bob said - that's the important bit.


A few other things i got from your post:

- You do know that you can use one material with several objects, do you?

- What will slow things down, is when there is lots of stuff on the screen at the same time, i.e. many polygons with many texture layers, which have to be calculated, although if your (uncompressed) age grows larger than the available amount of video RAM, I suppose you will get a lot of slow shunting of data from main memory.

- Sounds like you've already got square textures, but still - any textures will be rescaled at export, to power-of-two square sizes, so if you worry about deformation; do make your textures x=y to begin with and try to match shapes and proportions, to avoid some of the weaknesses of UV-mapping.

I may get rapped over the fingers over this, but I can't imagine any reason why a huge texture would affect performance, as long as it, along with everything else, fits, decompressed, into video memory, should it be absolutely neccessary to have one.
In addition to what Bob said about using a smaller texture often being barely noticeable, this can be especially true when you have something like a repeating pattern with different splotches of dirt on it - there you can often use two really small (pixel size) layers, one for the pattern and one for the variations, in place of a single large texture with everything on it - a technique you seem well familiar with, given how you have textured your terrain.
If your stencils are really large, do give that vertex painting a try. (devs: given some things said on the past: are stencils exported as 8-bit images, or 24/32? (this has had me worried, some :7))

If you want to experiment with the results from your lightmap, you could try fiddling about with your age using Plasmashop, post export. Plasma has gazillions of blending mode varieties, which we can not currently (afaik) set using pyprp.

[teedyo]

What Bob said - that's the important bit.
I may get rapped over the fingers over this, but I can't imagine any reason why a huge texture would affect performance, as long as it, along with everything else, fits, decompressed, into video memory, should it be absolutely neccessary to have one.

It's not the memory usage here that's the primary concern, but the time complexity for scaling those textures. It's O(n^2) to visit every pixel in an image. For arguments sake let's say it needs to be reduce by 1/4. It will normally be a much larger reduction. Then we have approximately 4(n^2) to visit every pixel and 3 neighbors to average. So for a 512x512 that's ~ 4x512x512 = 1,048,576 operations whereas for a 256x256 texture it's 4x256x256 = 262,144 ops. Now do this for every object that has a texture and you can see how it can add up. A 512x512 texture takes 4 times the processing time of a 256x256 texture. Put another way: If you get 30 fps using 256^2 textures, you may get only 7.5 fps using 512^2 textures. This is exaggerated of course; as it's ignoring the time to calculate the geometry.