<sturnclaw> fluffyfreak: I honestly think we should do the texturing on the generation thread and make the shader only handle display
<sturnclaw> there's a lot more logic which should go into texturing, e.g. mineral deposits, hot springs, biomes, etc.
<sturnclaw> I'd rather do a virtual-texturing approach, although that requires sparse textures and GL4.5
<sturnclaw> the problem is of course storing material indexes in vertex data in a way that naturally blends
<sturnclaw> fluffyfreak:
https://www.gamedev.net/articles/progra ... ain-r3278/
<sturnclaw> I need to figure out exactly what megatexturing is
<sturnclaw> but this looks like a step in the right direction
<sturnclaw> possible cons: time taken to re-generate the megatextures, doesn't cope well with fast flight, possibly high CPU cost
<sturnclaw> fluffyfreak: might have found something worthwhile
<sturnclaw>
https://kosmonautblog.wordpress.com/201 ... nd-tricks/
<sturnclaw> Links at the bottom of the article go to Frostbite presentations, still working on reading them
<sturnclaw>
https://developer.amd.com/wordpress/med ... ssion).pdf
<sturnclaw>
https://media.contentapi.ea.com/content ... field3.pdf
<sturnclaw> better links
<sturnclaw> fluffyfreak: this guy seems to have gotten as far as we have, on SM4.0 hardware to boot!
https://www.gamedev.net/blogs/entry/168 ... texturing/
<sturnclaw> We can probably only blend once, and probably only tap the detail texture thrice
<sturnclaw> Calculating the offset might be a problem, but with some clever use of derivatives it should be achievable
<sturnclaw> unfortunately I don't have the shader-fu required to implement it all right now
<sturnclaw> also to add to the stack of papers to read:
http://twvideo01.ubm-us.net/o1/vault/gd ... exture.pdf
<sturnclaw> The in-depth slides from GDC-07:
https://developer.amd.com/wordpress/med ... aph07).pdf
<sturnclaw> That in particular isn't really useful to our use case, as it involves a lot of offline rendering to generate shader combinations based on terrain tiles
<sturnclaw> , it does raise an interesting point - we may want some
<sturnclaw> ...and that's what I get for messing with line editing shortcuts
<sturnclaw> fluffyfreak: ctrl+F11 also opens the ship debug spawner menu, because I didn't see the shader reload command in Pi.cpp :D
<sturnclaw> fluffyfreak: there's something weird going on with the mipmaps for array textures
<sturnclaw> I'm sampling with textureLod(tex, uv, 9.0) - aka mipmap 10 - and still getting moire' patterns ... even though that should only ever return a single color
<sturnclaw> ...er, 10.0 for mipmap level 10
<sturnclaw> ah
<sturnclaw> MIN_COMPRESSED_TEXTURE_DIMENSION
<sturnclaw> FINALLY
<sturnclaw> FINALLY
<sturnclaw> who in their right mind calls glGenerateMipmaps() on a texture with all of its mipmaps filled out
<sturnclaw> more to the point, who STOPS GENERATING MIPMAP LEVELS WHILE THEY'RE BIGGER THAN 1x1!?
<sturnclaw> fluffyfreak: I apologize if I'm accidentally casting blame on you
<sturnclaw> texture creation absolutely should not be stopping while there's mipmap levels left and the size is non-zero
<sturnclaw> also min_compressed_texture_dimension should be bigger too
<sturnclaw> *smaller
<sturnclaw> 4x4 block is what DXT* et al standardize on
<sturnclaw> testing improvements to TextureGL now, hopefully we can drop MIN_COMPRESSED_TEXTURE_DIMENSION
<sturnclaw> because mipmap levels are required to pad to 4x4 from what I remember of the MS spec
<sturnclaw> maybe it'll break horribly, who knows!
<sturnclaw> found and fixed the moire' pattern bug
<sturnclaw> turns out if you don't upload mipmaps smaller than 16x16, OpenGL can't actually sample from a smaller mipmap when you're using less than 16x16 pixels of screen space
<sturnclaw> hmm... is 0.279 earth radii == 0.279 earth grav accurate? I feel like it isn't
<sturnclaw> among other things, having 0.022 earth masses seems to indicate there's an inaccuracy there
<ecraven> should not be, as volume is not linear with radius
<ecraven> but it all depends on the densities
<sturnclaw> looking at some other things in the system inspector, we're definitely calculating surface gravity as == earth masses
<sturnclaw> that's a bug!
<sturnclaw> fluffyfreak: I think we can get rid of MIN_COMPRESSED_TEXTURE_DIMENSION, unless there's a reason it's there in the first place. Anything coming in a compressed format will have a viable minimum block size down to 1x1, and anything uncompressed won't have mipmaps anyways
<sturnclaw> I think we're actually fairly close to being able to merge this thing, even as a basic first implementation. Blending might be a bit of an issue, but I'm sure I can work my way around it in one way or another
<sturnclaw> GL's MAX_ARRAY_TEXTURE_LAYERS value is required to be 64, so we have plenty of texture slots available for a planet
<sturnclaw> we could even pass uv1 as a vec3, encoding biome index in the third parameter, and use it to index into a 3D lookup texture
<sturnclaw> I'd imagine we won't use more than three or four textures for each biome, so that gives us plenty of wiggle room
<sturnclaw> anyways, I'm heading off early tonight.
<sturnclaw> heh, early. It's 2:30am here :P
* sturnclaw -> Zzzzzz
