AEcell - Cell Texture Pack - beta2 d/l

[Tabun]

Why not use (something like) this:
http://www.colorjack.com/sphere/
.. and pick a nice color from there? :]

[Silicone_Milk]

wattro,
I also noted that the PNG files seem to mess with the color tone for some reason when shown in a browser... hmmm... what background color would you prefer. I had thought of using white but that would be eye poking as well, and black would make the texture edges invisible.

cold bluish gray. like 3C4C4F or 636266

Neat link btw Tabun. Bookmarked.

[wattro]

yup, something simple like mid grey or something that SM suggested... just not orange! or use a subtle grey scale gradient

[AEon]

I'll simply use the BG color of the forum thread here, giving everyone the illusion they were actually part of the forum .

Recreated all of the original template textures evil lair created (with permission), and also with permission these textures will be available in the texture pack, making the texture_ae set complete. Started to make several textures more detailed, e.g. redid the original JP texture, colored the AP texture etc.

Hope fKd will release another map update with the textures soon, to give me a better feeling how these can be used, and what textures might still be required.

[fKd]

hahahah working away on it now... so much mapping, so little time

[AEon]

Bleeding of one texture edge to the other side of the texture, is probably a know pitfall for folks creating textures, but can something be done about it?

• 

As you can see the "end piece" a) is connected to the "med piece" b), created this ugly black thin seam. These brushes are set to grid. And the editor also shows the issue. The problem is with texture a): The black edge on the left side (indicated in green) seems to bleed ever so slightly to the right side.

I am including the tga (full quality) textures:

• Download: temp_aewall_texture_bleeding.zip (2.22KB) @ hugelaser.com

What am I doing wrong? Or is this simply a known issue forcing texture designers to have a one pixel overlap on all sides of the textures? If so, this would not be an option in this case using this rather simple design.

Any ideas, suggestions?

[fKd]

here is a wee build showing where im at now, hope this help AEon

http://www.filefront.com/14686053/Temp01.pk3

[Tabun]

Don't have a clue on the texture bleeding issue. All I know is that this was a standard "problem" with making skins for models (in a different way, since only edges that were connected on the model, but disconnected on the skinmap would "bleed" like that -- and that isn't a problem at all). Can't think of any clean solution for this, at the moment.

[o'dium]

The texture issue is something you wont be able to fix, sadly. The issue comes from the way textures are mipmapped; what you are seeing there is the texture being "softened" as such ingame so it doesnt look pixelated. The only cures for this are clamping the texture coords to the brush (in code), removing the gl call to soften the texture (in code), or making the texture a lot higher res (thus making the texture soften bleed less).

There is another option, and one which will work for this theme very, very well, but not for normal textures. Simply select the face with the issue, and scale it along the one axis a TINY ammount. Keep going until the black line disapears, and will will look perfect. Your lucky with this texture theme. Because its got no actual detail to the texture like your every day Q3 texture, you can scale it quite a bit and it wont look out of place or wrong at all. All you have to do, is simply scale it a TINY SMALL LITTLE ICKLE BABY ammount until the black line is gone, and tada, fixed.

[AEon]

o'dium,
thanks for clearing that up. fKd is using these two textures in the Quad room, in the predictable way (two end pieces one center piece), so the slight stretching should work.

As an easier alternative, one would make the brush 1u larger on the "open" side of the end piece, then simply fit the texture, make the brush smaller by 1u, and everything should still look fine.

fKd,
hehe... it's really cool to see "my" (actually Andromeda traced) textures used in your map. I see that the "deco" textures are especially popular - like placing "paintings" on walls. Amazing level of detail in that map. Seeing my re-vamped JP, made me smile as well. Would be great if that map was released as a texture set demo, before you go for the real texturing. Your map seems to be proving more and more that the texture set could actually be used to build a beautiful map (not just as a temporary placeholder).

[fKd]

cheers improvments are still coming along, just testing out details in the 1 room at the mo, but after this weekend more should be done. again, all the time and effort you have put into this is really above and beyond, cheers man

[AEon]

Happy to hear and see that they are being out to good use. Presently working on the second generation of textures... put less pompously that means, going through the very first created textures, I am adding more "color" and detail. To make them look more interesting.

[AEon]

Added a few new textures, added some coloring and datail to others. Note the AP and JP, rebuilt the fence textures:

• [lvlshot]http://aemap.hugelaser.com/misc/temp_ae_textures14.png[/lvlshot]

Next... create gray versions out of all of them. (PGN in Firefox, alas messes up the colors )

[Infernis]

cheers improvments are still coming along, just testing out details in the 1 room at the mo, but after this weekend more should be done. again, all the time and effort you have put into this is really above and beyond, cheers man

Amen!

[AEon]

Note to anyone planning to use the texture set:

• It makes *no* sense whatsoever trying to convert the TGA images in my set to JPG. This messes up the precision of the textures, introduces color artifacts, plus and this is the most important reason: The packed TGA images in the PK3 are *always* significantly smaller (compression works really well), and any 100% JPG version. So don't convert them... or "the texture Gods will be on you so quickly it will make your head swim" .

[AEon]

On lighting...

• 

The texture on the left uses:

• q3map_lightsubdivide 128
  q3map_surfacelight 1600

to light the map. The one on the right uses this:

• q3map_backsplash 0 0 // Avoid point source lighting on face
  q3map_lightsubdivide 128
  q3map_surfacelight 1600

Now for most point sources the former should be fine, but IMO one should "avoid point source lighting on texture face" for these wider texture lights.

IOW use the lighting on the right. Agreed?

If you know of a even better way, please point it out.

[obsidian]

It doesn't look quite right. There should usually be at least a bit of backsplash when considering radiosity and light bouncing off the surface and back onto the object. The point with backsplash is to control the distance and percentage so you don't get any "hotspots", it should only be fully disabled on surfaces like skys.

Try a relatively low % value and a higher than default distance value. This should move the light source away from the surface with a low amount of light bouncing back at it.

Oh... perhaps increase the subdivide to 64 in this case and lower the intensity value a bit.

[AEon]

As a reminder to myself (from the Shader manual):

• q3map_backSplash percentage distance
  
  A surface light is lit by itself, often causing areas of higher light intensity than other areas. q3map_backSplash moves the light source away from the surface of the shader, allowing it to create smoother lighting over the face. By default, all shaders are assigned backsplash values, 0.05 for the percentage, 23 units for the distance.
  
  • percentage : Specifies the intensity percentage of the light generated by q3map_surfacelight to be redirected back at the surface. Use a value of 0 or a negative value to disable back splash lights.
    distance : Distance of the back splash lights from the surface.

obsidian,
I'll try 0.005 for percentage and 30u distance, and the subdivide 64. Well, I'll probably create something like 10 shaders and try those out, then take a screenshot, and we can see what works and what does not.

Thanks for the tip.

[AEon]

The more detailed textures take quite some time to create...

• [lvlshot]http://aemap.hugelaser.com/misc/temp_ae_textures16.png[/lvlshot]

[AEon]

Testing the lighting, in a completely dark area of my test map:

• [lvlshot]http://aemap.hugelaser.com/misc/temp_ae_textures17.jpg[/lvlshot]
  [lvlshot]http://aemap.hugelaser.com/misc/temp_ae_textures18.jpg[/lvlshot]

• q3map_backSplash percentage distance
  q3map_lightsubdivide factor

Values are: percentage distance factor

1. 0.005 30 128
2. 0.005 30 64
3. 0.001 30 64
4. 0.001 40 64
5. 0 0 64 (no backsplash)
6. 0.05 23 128 (default)

• 1/2 A finer subdivision, 128 to 64 does not yield much of a difference. So the less resource hungry 128 should be fine.
• 2/3 5x the blacksplace % value seems to make the wall slightly brighter (as expected).
• 3/4 Increasing the distance (30 to 40; from the light was my guess), actually makes the light texture better lit. Strange.
• 4/5 No backsplash, darker light texture.
• 5/6 Using default backsplash is too strong.

The values 0.02 30 128 might hit the spot.

Update: The default values are in fact wrong, you need to use far higher percentages to actually see anything. The differences above seem to have to do with perspective and imagination, in the first 4 cases. Hmmm... A useful value set seems to be: q3map_backsplash 1 23:

• [lvlshot]http://aemap.hugelaser.com/misc/temp_ae_textures19.jpg[/lvlshot]

Left uses these new values, right the way the texture lights without a q3map_backsplash command in the shader.

Will be using these new values...

[AEon]

Whee, more than 200 textures done...

• [lvlshot]http://aemap.hugelaser.com/misc/temp_ae_textures20.png[/lvlshot]

(BTW: The "5 gate" based on Hiptshot's design in Solar, I think he did it as least).

[fKd]

can you do 1 to 5? be good location markers sorry about being a bit quiet as of late, been side tracked into making a level for operation flashpoint 2. its interesting as one of my flatmates has it so i can play lan. fool does not play q3 because i always waste him :/ but yeah great stuff so far, can i use 200 textures? you bet i can

[AEon]

About the numbers, hmm... no idea ... might need to find a font that actually has that style... I'm not that great at creating on-the-fly "vector" fonts. Will look into it.

[AEon]

I am sorting the gray textures to be colored via shaders into different folders:

• temp_ae_base (evil lair's original template textures)
  temp_ae_grate
  temp_ae_light
  temp_ae_floor
  temp_ae_pads
  temp_ae_pipes
  temp_ae_sfx
  temp_ae_trim
  temp_ae_wall

Though this is practical, the paths to the textures point to 9 different subfolders. I am not completely sure this is a good thing in the textures menu of GTKradiant. This would let me separate the shaders into 9 files as well, from a code perspective this is "good", but again this will spam the shaderlist.txt with *9* entries instead of e.g. one temp_ae.

Seperation would have the advantage that folks that only want to use the original "base" set of textures can do so easily, and ignore the other folders. Those folks looking for more wall or floor relates texture will find them more quickly.

The downside when placing everything into one folder is the spamming of 200 textures. You'd have to wade through all of them to find what you are looking for.

Any preference here, Sock?

[Pat Howard]

I'd rather you categorize them. Having 200 textures constantly up in your window while editing can be really overwhelming.