Texture Coords
Blitz3D Forums/Blitz3D Programming/Texture Coords
| ||
| How does oione assign vertices to a texture coord set? As I (poorly) understand the command, TextureCoords command requires some way of having previously established different "UV sets" for certain vertices. However, I can't find any commands which might do this. |
| ||
| All vertices already belong to both sets. People normally only bother to use (or set) the first set since, apart from lightmaps, it's rare to need two textures on an object anyway. You can set the second coords by specifying the second set in the final (optional) parameter to VertexTexCoords; otherwise the set is on whatever the default values are - 0, I assume. But no, there's nothing special you need to create to make this work, the coords merely have to be applied. |
| ||
| Ah VertexTexCoords, that was he command I was looking for :) If it matters, the reason for wanting to use this approach is because I am working on a 'planet' mesh, which, to differentiate between sun-facing and shadowed hemispheres, I need to split a sphere in two and texture each hemisphere separately. My initial idea was to simply use two surfaces, but that entails using the Brush / Paint comand and I am never too comfortable with a lot of that stuff, I find working with textures/entitytexture is much easier (just personal preference I guess) In case you're wondering why I don't just let the dark side fall into shadow die to lighting normally, it's because I want the "dark-side" to display lights from cities etc. so using a separate "dark" texture with full-bright EntityFX seems to be a good way to do this. |
| ||
| Sounds like a pretty cool visualization! Unless your planet has ...unusual geography, you probably don't need a second UV set though: the two world maps will surely be the same size and shape and so on, with only the colours changed? If you try to use two texture coord sets I think you;d end up with the same cities on one side and the same continents on the other regardless of the time of day (maybe I misunderstand what you mean...). The way I would instinctively do this is with two surfaces (or meshes, probably makes little difference but surfaces would be slightly more efficient), and use vertex alpha to cut out half of the world surface from the one supposed to go over the top. That'd also give you a nice blurry terminator if you got it right. Since planets are spherical (again, making assumptions about your geography), you won't have the alpha-Z-sorting problem as a sphere is perfectly convex. In fact, with clever management of vertices you could do this all with one texture (holding day and night in two halves) and one surface. Z-fighting is not usually a problem as long as you explicitly position vertices: the ones last placed by hand in the same position will usually render correctly (alternatively, you could use a raised daytime surface if the camera is far enough away). |
| ||
| Unless your planet has ...unusual geography, you probably don't need a second UV set though: the two world maps will surely be the same size and shape and so on, with only the colours changed? If you try to use two texture coord sets I think you;d end up with the same cities on one side and the same continents on the other regardless of the time of day (maybe I misunderstand what you mean...). I think you understood correctly. It appears as though you're right, both textures are applied across ALL vertices but the 'last one placed' seems to take precedence (as might be expected). The way I would instinctively do this is with two surfaces (or meshes, probably makes little difference but surfaces would be slightly more efficient), and use vertex alpha to cut out half of the world surface from the one supposed to go over the top. That'd also give you a nice blurry terminator if you got it right. Since planets are spherical (again, making assumptions about your geography), you won't have the alpha-Z-sorting problem as a sphere is perfectly convex. I never thought of using the two mesh approach (Well, not by Alpha-ing out halves of two spheres - I'd only tried making two hemispheres but that had its own problems) I think that using two meshes as you say sounds like a great approach, and indeed, the planet geography is only defined by the texture 'colours', so using primitive sphere's is fine (oblateness can be applied conveneiently later) - The two halves should fit 'snugly' together, so no worries about z-ordering either! Thanks for the advice and help :) As for thee single texture possibility, I don't wanna risk trying that for now. The planet will need to react dynamically as it is shown orbiting the star, so that will already involve continuous updating of the positioning of the texture(s) - If it were a static body, then a single texture wouldn't be an issue, but it's possibly a little overtechy for my understanding and needs right now... If I get things working well with two textures, maybe I'll try that later! |
| ||
| Using DOT product is a great way to set the alpha of your planet layers. Consider a planet object composed of 3 layered spheres. Each sphere is epsilon (0.0001) slightly bigger than the other so they're layered and the rasterizer can render them without Z-fighting. - The inner sphere is textured with plain-day texture. - The middle sphere is textured with night-time texture. - The outer sphere is textured with the transparent full-bright night-time city details (this layer could be merged into the same texture as the night-time, but keeping it separate gives you more control - maybe at some point you want the city to remain unlit even at night). All spheres have a high segment count (32 or 64 for instance), so you have a smooth surface and when changing alpha the user doesn't notice the triangulation effects of the per-vertex shading that Blitz3D uses. The spheres don't rotate - they stay still. It's the layering and ever-changing vertex-alpha that gives the effect of a sun-lit planet. The vertex alpha logic could be the following (EDIT: optimized the code a bit): PSEUDO-CODE
;Sun-to-planet vector. In other words, the sunlight vector.
Local stpX# = EntityX(sun,True) - EntityX(planet,True)
Local stpY# = EntityY(sun,True) - EntityY(planet,True)
Local stpZ# = EntityZ(sun,True) - EntityZ(planet,True)
For middle and outer spheres {
For every vertex of the mesh {
;Calculate DOT product from sunlight and vertex normal.
Local DOT# = dotProduct(stpX, stpY, stpZ, VertexNX(), VertexNY(), VertexNZ())
;If DOT > 0, the vertex is at day time. Vertex is pointing towards the sun and should be hidden (since it belongs to shadow or city-light layers).
;If DOT < 0, the vertex is at night time. Vertex is pointing away from the sun and should be shown.
VertexColor 255,255,255,(DOT < 0.0)
}
}
;No need to change alpha of inner sphere, as it's occluded by the others.
Function dotProduct(nx1#,ny1#,nz1#,nx2#,ny2#,nz2#)
Return nx1*nx2+ny1*ny2+nz1*nz2
End FunctionLast edited 2012 |
| ||
| Thanks, Kryzon I never considered Dot-Product calculations for identifying the meridian, but that's certainly a good way to go about it. What I have is something similar, as suggested, the planet won't need to rotate as its only the textures that change (or different sphere sections becoming visible/hidden) My only concern with this approach, I think is the speed. I am also using Linepick (alternative solutions welcome :) ) to check for eclipses and such for objects where the planet is between them and the sun - presumably with multiple and hidden geometry representing the planet, multip[le Linepicks would be required? |
| ||
| Hi. Yeah, I wasn't familiar with dot-products until recently and they're great for comparing orientations of objects\vectors and other stuff. A normalized Dot-Product would also allow one to smooth-out the transition from day to night, if they don't want that hard edge at the meridian. Regarding speed, I didn't test it but dots should run pretty fast (they're simple math and memory queries). If you want to 'shade' the planet based on occluders (meteors, moons, other planets etc.) there are a few things you can try: - Use a dynamic shadow system, like the free Devils Child's Stencil Shadow engine (though Creative Labs Inc. holds a patent on one of the shadowing methods used by this lib, so no commercial use for this one even if Devils has licensed it so). - FastEXT's shadow-map system is commercial, but is pretty much the only dynamic shadow-map system for Blitz3D that's adequate for production uses (there used to be SSwift's, but it's not available anymore). The bloom effects, god\sunrays and other post-filters from this lib will also make your space scene much more sophisticated. - Back with that 3-layer planet theory, if you can extrude the shadow-volumes of the occluders, then test for the intersection of this volume with the planet and all other objects in the scene, then figure the vertices from the shadow and\or city-detail layers that are closest to the perimeter of the intersection and turn their alphas to 1.0, so you get that spot of shadow on the planet wherever the sun is eclipsed. |
| ||
| quite interesting! a year ago i needed more or less the same and my aproach was: one sphere with the day texture in one layer and a second Mask1 texture another sphere with the night texture in one layer and a second Mask2 texture Mask1 and Mask2 was complementary or one the negative of the another. Later playing with blend mode i got the result, i never thinked about playing with vertexcolour i change the u,v coords of the mask textures. take a look:  here is the code (.bb) an executable and textures: https://sites.google.com/site/odriozolajuanignacio/earth%20night%20day.zip i'll try the Kryson's way just to play a while with the concept. thank's Juan |
| ||
| Credits go to Yasha for suggesting the use vertex-alpha for this :) |
| ||
| Wow, that's some great stuff! Thanks very much, Kryzon & Charrua (and Yasha!) - Back with that 3-layer planet theory, if you can extrude the shadow-volumes of the occluders, then test for the intersection of this volume with the planet and all other objects in the scene, then figure the vertices from the shadow and\or city-detail layers that are closest to the perimeter of the intersection and turn their alphas to 1.0, so you get that spot of shadow on the planet wherever the sun is eclipsed. Seems to be essentially what any 'shadow system' would try to do anyway, so probably better to use an existing "solution" rather than try and reinvent my own wheel ;) I think what I'll do for now, is have a go at Kryzon's method, see how I get on, and post back here with some code! I am a little 'afraid' to use FastExtension but then again, I've gottent the license and it's inevitable I should bite the bullet and get to grips with it sometime! |
   |