Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Craft sphere texture

2»

Comments

  • Posts: 509

    Fixing those "small" issues is what makes my code slower. There is probably some optimisation to be had in my code, but the intention is to serialise the uvs rather than have to calculate them afresh every time.

    The smooth isosphere cannot be done just by assigning texture coordinates to positions. You will always end up with defects on the seam. Again, that's what all the extras in my code fix.

  • edited March 2018 Posts: 2,270

    @Loopspace @dave1707 - looking at the plotting of points used for texture allocation, in the project written by @dave1707, you can see a series of longitudinal lines covering almost the height of the texture. There are only two points at the poles. If you triangulate from the longest longitude you are left with 4 triangles in each corner of the texture - it may be these allocations that are causing the problem.

  • dave1707dave1707 Mod
    Posts: 9,287

    @LoopSpace Let me ask you a question, does the indices array contain the index into the positions table to get the position for each corner to create the triangles.

  • Posts: 509

    @dave1707

    Let me ask you a question, does the indices array hold an index into the positions array used to form the 3 vertices of each triangle.

    Yes. The indices array should be thought of as consisting of triples, each triple being the indices of three positions making up a triangle.

    In the non-smooth case, each position is contained in a unique triangle. This makes it possible to simply assign the texture coordinates based on the triangle. In the smooth case, positions are re-used and for positions near the seam (and poles) this means that they can have more than one texture coordinate. My code deals with this by duplicating those positions. This is the only way to fix this.

  • dave1707dave1707 Mod
    Posts: 9,287

    @LoopSpace That’s what I thought. I’m only using the position array in groups of 3 to create the triangles in my code. For the rough icosphere, only using the position array works OK. For the smooth icosphere, the majority of triplets are correct, but there are a few triplets that span across several other triangles which is what causes a problem in my code. I don’t see why the position array can’t have the correct info in both cases.

  • Posts: 509

    @dave1707 The way the icosphere is set up, in the non-smooth case then every position is in a unique triangle. This leads to vertices being duplicated quite a lot (roughly five or six times) but this is needed because although the positions are the same for each re-use of the vertex, other data (specifically the normals) is not.

    However, in the smooth case, the normals depend only on the vertex and not on the triangle and therefore the vertices can be re-used in different triangles. For the vast majority of the vertices, this is okay with the texture as the texture coordinates only depend on the position on the sphere.

    Where this fails is at the edges of the texture, which with the usual sphere wrapping are at the poles and at the seam. At these places, more than one point on the texture goes to the same point on the sphere. This is perhaps most obvious at the poles where the entire top of the texture maps to the north pole (and bottom to the south pole). Therefore, the texture coordinate at the north pole depends on which triangle is under consideration. So the pole needs duplicating, once for each triangle it is in. A similar thing happens down the seam.

  • dave1707dave1707 Mod
    Posts: 9,287

    @LoopSpace That explains why in my smooth icosphere the bad textures are at the poles and at certain places along the seam. I’ll have to keep looking at the way I do my code to see if there might be an easy way to fix the bad spots. The fun is in trying to get it to work, but I don’t want to spend a lot of time trying to fix it because I probably won’t do anything with it anyways.

  • dave1707dave1707 Mod
    Posts: 9,287

    @LoopSpace Here’s the problem I was running into using the positions array. The first image shows a grid of my longitude and longitude points. This is for the smooth icosphere. I draw the triangles in white and you can see where the green triangles and the green line across the middle are the problem areas. They cross over several other triangles. The second image is for the rough icosphere and you can see all the triangles are OK. Ignore the long triangles that run from the left edge to the right edge. Those would actually connect in the opposite direction.

  • JohnJohn Admin Mod
    Posts: 643

    It seems like my icosphere generator is causing a few issues for people. Honestly the best solution would probably be for me to include a UV sphere generator as I think they are much easier to properly texture automatically.

    @dave1707
    The reason why you see different mesh data between flat and smooth icospheres is due to the way it shares normals in smooth meshes to save on vertices.

  • dave1707dave1707 Mod
    Posts: 9,287

    @John I’ve been playing around with the flat and smooth icospheres trying to see why the smooth icosphere is so hard to texture. I’ve come to the conclusion that the smooth icosphere can’t easily be textured and it might not be worth trying. The flat icosphere texture is easy and fast and looks OK at the high levels. I don’t know what your UV sphere generator is, but anything is worth a try.

  • edited April 2018 Posts: 2,270
    @John - it's been kinda fun exploring the options for a realistic sphere, we have some good expertise on the forum - @dave1707 and @LoopSpace generating some good options. I think the icosphere is fine for the Craft environment. I need a more realistic sphere which can be viewed from inside.

    I have a generator from the @Jmv38 sphere tutorial which works fine, do mesh systems work well alongside Craft systems do they use the same co-ordinate system for 3D space?
    Also @dave1707 has an excellent sphere generator.

    Were you proposing to map out a UV texture for the icosphere?
  • Posts: 509

    @John, By a "UV-sphere generator" do you mean one that creates the vertices based on longitude and latitude? It's not really important what the underlying triangulation is, but it would be easier to have the UV coordinates already in place rather than having to create them afterwards. If creating the UVs afterwards then it doesn't really matter how the vertices were constructed. As you point out to @dave1707, the main issue is the vertex sharing in the smooth version but that could be an issue with a longitude-latitude based construction as well unless you explicitly duplicate the required vertices.

    My routines texture both versions of the icosphere just fine - I'm not sure why @dave1707 says it is hard as I've given a solution. It just needs serialising to make it faster, but building it in to the original construction would be equally fine. With the smooth version, it figures out the needed duplications and adds in the relevant vertices.

    @Bri_G The point of my PseudoMesh class is to convert old-style meshes into craft models that can then be used with models. My recent run of videos (starting with ) all work using this: create a mesh and then convert it to a model. Since I already have code for spherical meshes (and more) which are already prepared for textures, I don't actually need to use the icosphere model myself.

  • dave1707dave1707 Mod
    Posts: 9,287

    @LoopSpace I guess my use of hard was wrong. I should have use time consuming since it takes a long time as you pointed out.

  • Posts: 2,270

    @LoopSpace - thanks again, I completely forgot that you had built PseudoMesh for that purpose. Since obj files are Craft compatible seems a good way to go. Will revisit your code.

  • dave1707dave1707 Mod
    edited April 2018 Posts: 9,287

    @Bri_G Above you said you want to view a sphere from the inside. I took my above program, chopped it up a little, and added some code to let you view it from the inside. Just keep zooming in and then slide your finger around to rotate the sphere.

    Removed the code. See updated code below.
    
  • Posts: 509

    @Bri_G If you use my PseudoMesh class then there's an invertNormals method which swaps the direction that the mesh is viewed from. So using that before converting the mesh to a model changes it to inside-out.

  • edited April 2018 Posts: 2,270
    @dave1707 - thanks for the update on your sphere code, works great. I can see both external and internal views of the sphere. I noted your tidying up around the seam.

    Is the code reversing normals in the section which creates a uv table?
  • dave1707dave1707 Mod
    edited April 2018 Posts: 9,287

    @Bri_G I didn’t tidy up around the seam. The problem is doing a smooth sphere as opposed to the flat sphere. My code works OK for the flat sphere (where you can see the triangles), but there are still a few areas that are bad for the smooth sphere. As you increase the level from 0 to 5 for the flat sphere, the triangles get smaller and the sphere looks smoother. As for reversing the normals, I don’t do anything with the normals. I still don’t know the exact usage for normals so I leave them alone. I think they’re used for lighting and reflections and I hope @LoopSpace will give a good explanation of they’re use. To get the texture to show from inside the sphere, I just add the reverse of the indices table to itself. So the indices table is twice it’s size. Half of the table has the indices values going in a clockwise direction and the other half goes in a counterclockwise direction. So how you view the texture depends on the winding direction of the indices values. I could change the code so you can’t see the sphere from the outside, only once you get inside. That might make for an interesting game. I’m cleaning up my original code to make it smaller and faster. I’ll post that when I’m done. So far I can texture a level 5 icosphere with outside and inside views in about 1/2 second.

    EDIT:I tried making a sphere invisible except from the inside, but it didn’t work. What happens is you don’t see the outside of the sphere, but you can see the inside. It’s as if the near part of the sphere is invisible and you can see the inside of the far side.

  • Posts: 509

    @dave1707 I had a go at explaining normals here.

  • dave1707dave1707 Mod
    Posts: 9,287

    @LoopSpace That looks like a very informative link. I don’t recall seeing it before. I’m going to start reading it now.

  • Posts: 509

    @dave1707 As ever, if you have any questions or suggestions, please do share so that I can make it better. (It was written a while ago, well before craft came on the scene, so it doesn't address the one-sidedness of craft objects that you describe above, but hopefully explains why normals are important.)

  • dave1707dave1707 Mod
    Posts: 9,287

    @LoopSpace I read the section on Normals and excluding the vector stuff, I think I understand what it’s doing. I’ll have to write a simple example for myself and play around with the values in the Normal array. Thanks for the link, I’m not sure why I haven’t seen it before now. Do you have links to more information you would like to share. I’ll go back at a later time and read the full doc.

  • Posts: 509

    @dave1707 All my writings on Codea are listed on this section of my website. Haven't written anything for a while, but am happy to take requests ...

  • dave1707dave1707 Mod
    Posts: 9,287

    @LoopSpace Thanks for the link. I have it bookmarked and will look thru it later.

  • dave1707dave1707 Mod
    edited April 2018 Posts: 9,287

    Here’s my latest texture code. I don’t like it because it’s sloppy and has hard coded values. This works for both flat (triangles) and rounded (smooth) icospheres. It handles the bad triangles that were showing up in the previous rounded icospheres. The higher the level, the better the texture looks. It will do flat and rounded level 5 icospheres in less than a half second on my iPad Air, doing both the outside and inside texture. I’m starting to understand the problems with texturing the icospheres and hopefully in future versions, I’ll be able to cut the size of the code and remove the hard coded values. I changed the texture map from my other versions just to give a better view of the texturing. Also, the lower level icospheres don’t texture as smooth at the poles as I want and maybe I’ll get those fixed too.

    Code deleted, see updated code below.
    
    
  • Posts: 2,270
    @dave1707 - wow, that's superb, I can't see how you are going to improve that. Very neat finishes at the top and bottom of the sphere. I'm sure that I found a reference in which the sphere was built largely as an icosphere but had the usual rectangular/triangles for the top and bottom.

    I assume generation of the craft icosphere vertices is rapid and the slow times in the Codea Craft are due to texturing, is that true?
  • Posts: 509

    @dave1707 With each iteration you are approaching my code ...

    The poles are tricky because of their interaction with the seam. Since the poles officially lie on the seam, the triangles involved in the poles will pass a simple test for being on the seam, but not all those triangles should be shifted. It took me a few iterations to figure that one out.

  • dave1707dave1707 Mod
    Posts: 9,287

    @Bri_G As for improvements, I would like to get rid of the hard coded values and condense the one section of code that’s used by them. The level 0 icosphere is created by Codea with a flat surface at the top and bottom, whereas the level 1 thru 5 have the point at the top and bottom. So a level 0 icosphere wouldn’t texture at the top and bottom very good unless more calculations are done to rotate it first to get the point at the top and bottom. The time for Codea to create a blank level 5 icosphere is .10 seconds. Using my code to texture a level 5 icosphere both inside and outside takes .36 seconds. That’s on my iPad Air. @LoopSpace I’m not having trouble with the poles. The problem I’m having is with the rounded icospheres because so many of the points are shared with other values. When one of those points need to be shifted, then new values for the 3 points of the triangle need to be created and I have to be careful how they’re created.

  • dave1707dave1707 Mod
    Posts: 9,287

    Here’s an updated version. I removed the hard coded values. I still don’t like the way the level 0 icosphere looks, but why do a level 0 when the other levels are fast. There are still some minor pole problems, but they’re not that noticeable.

    displayMode(FULLSCREEN)
    
    function setup()   
        -- create test texture
        myImg=image(1024,512)
        setContext(myImg)
        background(170, 198, 223, 255)
        fill(255,0,0)
        ellipse(250,256,200,100)
        fill(0,255,0)
        ellipse(900,256,100,200)
        fill(255,255,0)
        rect(512,320,256,128)
        stroke(255,0,0)
        strokeWidth(8)
        line(0,0,1024,512)
        line(0,512,1024,0)
        strokeWidth(4)
        stroke(255,255,0)
        line(4,0,4,512)
        line(1020,0,1020,512)
        line(0,508,1024,508)
        line(0,4,1024,4)
        fill(0, 19, 255, 255)
        fontSize(25)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcde",512,490)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcde",512,22)
        fontSize(40)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",512,512*.8)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",512,512*.65)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",512,512*.5)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",512,512*.35)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",512,512*.2)
        stroke(0)
        strokeWidth(3)
        for z=0,1024,64 do
            line(z,0,z,512)
        end
        for z=0,512,32 do
            line(0,z,1024,z)
        end
        setContext() 
        -- end test texture   
    
        level=1     --  0 thru 5
        flat=true  -- true (triangles) or false (rounded)
        insideView=true -- show inside view of sphere
    
        assert(craft, "Please include Craft as a dependency")
        assert(OrbitViewer, "Please include Cameras (not Camera) as a dependency")        
        scene = craft.scene()
        v=scene.camera:add(OrbitViewer, vec3(0,0,0), 350, 0, 600)
        createSphere()
    end
    
    function draw()
        update(DeltaTime)
        scene:draw()
        sprite(myImg,WIDTH*.85,100,300)
    end
    
    function update(dt)
        scene:update(dt)
        sph.rotation = quat.eulerAngles(-90,0,0)
    end
    
    function createSphere()
        sph=scene:entity()
        sph.position=vec3(0,0,0)
        sph.model = craft.model.icosphere(100,level,flat)
        sph.material = craft.material("Materials:Standard")    
        sph.material.map=myImg
        local llTab={}  -- latitude, longitude table
        local uvTab={}  -- uvs table    
        local seam=0
        local ax,bx,cx,ay,by,cy,c,lat,lon    
        -- convert sphere positions to latitude and longitude
        local posTab=sph.model.positions
        local norTab=sph.model.normals
        local colTab=sph.model.colors
        local indTab=sph.model.indices
        --for a,b in pairs(sph.model.positions) do
        for a,b in pairs(posTab) do
            c=b:normalize()
            lat=math.deg(math.asin(c.z))+90
            lon=math.deg(math.atan2(c.y,c.x))
            table.insert(llTab,vec2(lon,lat))     -- save lon, lat in table
            if lon//1==-149 then    -- get exact value of seam
                seam=lon
            end
        end  
        -- shift points on the left side of the seam to the right side 
        for a,b in pairs(llTab) do        
            b.x=b.x-seam
            if b.x<-.01 then
                b.x=b.x+360
            end
        end      
        -- shift individual point of 3 if needed  
        for z=1,#llTab,3 do
            ax,ay=llTab[z].x,llTab[z].y
            bx,by=llTab[z+1].x,llTab[z+1].y
            cx,cy=llTab[z+2].x,llTab[z+2].y
            if ax>250 or bx>250 or cx>250 then
                if ax<.01 then 
                    ax=360
                end
                if bx<.01 then
                    bx=360
                end
                if cx<.01 then
                    cx=360
                end  
            end 
            if ay==0 or ay==180 then
                ax=(bx+cx)/2
            elseif by==0 or by==180 then
                bx=(ax+cx)/2
            elseif cy==0 or cy==180 then
                cx=(ax+bx)/2
            end 
            -- create uv table
            table.insert(uvTab,vec2(ax/360,ay/180))
            table.insert(uvTab,vec2(bx/360,by/180))
            table.insert(uvTab,vec2(cx/360,cy/180))
        end
    
        -- fix bad triangles on rounded icospheres
        if not flat then
            for z=1,#indTab,3 do
                v1=indTab[z] v2=indTab[z+1] v3=indTab[z+2]
                u1=uvTab[v1] u2=uvTab[v2]   u3=uvTab[v3]
                if u1.x<.005 or u1.x>.995 or u2.x<.005 or 
                        u2.x>.995 or u3.x<.005 or u3.x>.995 then
                    v=0
                    if uvTab[v1].x>.5 then
                        v=v+1 
                    end
                    if uvTab[v2].x>.5 then
                        v=v+2  
                    end
                    if uvTab[v3].x>.5 then
                        v=v+4 
                    end        
                    xxx=0
                    if v==1 or v==6 then
                        xxx=z
                    elseif v==2 or v==5 then
                        xxx=z+1
                    elseif v==3 or v==4 then
                        xxx=z+2
                    end
                    if level==1 and (v==3 or v==4) then
                        for m=0,1 do
                            local val=indTab[z+m]
                            table.insert(uvTab,vec2(1-uvTab[val].x,uvTab[val].y))
                            table.insert(posTab,posTab[val])
                            table.insert(colTab,colTab[val])
                            table.insert(norTab,norTab[val])
                            indTab[z+m]=#uvTab                    
                        end  
                    elseif xxx>0 then
                        val=indTab[xxx]
                        table.insert(uvTab,vec2(1-uvTab[val].x,uvTab[val].y))
                        table.insert(posTab,posTab[val])
                        table.insert(colTab,colTab[val])
                        table.insert(norTab,norTab[val])
                        indTab[xxx]=#uvTab
                    end
                end            
            end
        end
        sph.model.indices=indTab
        sph.model.uvs=uvTab 
        sph.model.positions=posTab
        sph.model.colors=colTab
        sph.model.normals=norTab
        -- update indices table for inside view
        if insideView then
            local ind=sph.model.indices 
            for z=#sph.model.indices,1,-1 do
                table.insert(ind,ind[z])
            end
            sph.model.indices=ind
        end
    end
    
  • Posts: 2,270

    @dave1707 - found a funny!! Set the size of the sphere to 800 and run, You are inside the sphere and there is a smaller untextured sphere inside coloured grey. The inside sphere responds to the two finger shrink/enlarge in the opposite way to the big sphere that you are inside. Intriguing, is the inner sphere the sphere you added for internal viewing? it looks like the second sphere may not be necessary - just the inversion of the normals as described by @LoopSpace.

  • dave1707dave1707 Mod
    Posts: 9,287

    @Bri_G That has something to do with the limit of the camera. If you add
    v.camera.farPlane=3000 after v=scene.camera:.... and before createSphere() then you don’t get it. Without the farPlane, then you’re looking into dead space.

  • Posts: 2,270

    @dave1707 - thinking about it, it makes sense, if you build a reverse sphere inside another, as part of that sphere, and you increase the size of the outer sphere; then the inner sphere will move in the opposite direction ie towards the centre and hence shrink.

  • dave1707dave1707 Mod
    Posts: 9,287

    @Bri_G I’m not building a reverse sphere, all I’m doing is allowing you to see the texture of the original sphere from the inside. Depending on the direction that you define the 3 points of the triangle defines which direction you can view the texture from. So the indices table has the values winding in one direction and I add the table to itself reading the table in the reverse order. So the indices table has the points winding in both directions which allows you to see the texture from both sides.

  • Posts: 2,270
    @dave1707 - your right but isn't that just hiding the other sphere, took it down to a setting of 1440 for the farPlane and still there. At 1500 it's gone. Just feel it's more unnecessary work for the graphic processors than needed, and curious to know what it is.
  • dave1707dave1707 Mod
    Posts: 9,287

    @Bri_G There isn’t another sphere, just the one I create. What you’re seeing is a hole in the viewing area because of the way the camera works. As you get closer to the hole, it gets bigger and looks like you’re looking at a black sphere. @Simeon or @John will have to explain it because they’re the ones who wrote Codea. All I know is the farPlane fixes it because it allows the camera to see farther away.

  • dave1707dave1707 Mod
    edited April 2020 Posts: 9,287

    @Bri_G Here’s my latest texture code. I think I have all the kinks worked out for all levels both triangular and smooth. It’s a lot simpler than what I had before. With my other code I didn’t understand everything that was happening, but as I wrote more and more versions, I started to get an understanding of what was going on. Even though the code is smaller, it’s a little slower. Here are approximate times in seconds on my iPad Air for all levels and shapes.

    EDIT: I think this version takes care of the poles for all levels except 0 which doesn’t have a pole but a flat surface.

    EDIT: I made changes to the code below to increase the speed. On my iPad Air, the level 5 smooth icosphere that took .662 now takes .58 seconds. Not much of an increase, but an increase. On my iPad Pro, it takes .25 seconds.

    Level     Triangular  Smooth
    0           .088       .090
    1           .088       .088
    2           .096       .094
    3           .122       .123
    4           .210       .230
    5           .591       .662 
    
    --displayMode(FULLSCREEN)
    
    -- created by dave1707
    
    function setup()  
        -- create test texture
        myImg=image(1024,512)
        setContext(myImg)
        background(170, 198, 223, 255)
        fill(255,0,0)
        ellipse(250,256,200,100)
        fill(0,255,0)
        ellipse(900,256,100,200)
        fill(255,255,0)
        rect(512,320,256,128)
        stroke(255,0,0)
        strokeWidth(8)
        line(0,0,1024,512)
        line(0,512,1024,0)
        strokeWidth(4)
        stroke(255,255,0)
        line(4,0,4,512)
        line(1020,0,1020,512)
        line(0,508,1024,508)
        line(0,4,1024,4)
        fill(0, 19, 255, 255)
        fontSize(25)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcde",512,490)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcde",512,22)
        fontSize(40)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",512,512*.8)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",512,512*.65)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",512,512*.5)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",512,512*.35)
        text("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",512,512*.2)
        stroke(0)
        strokeWidth(3)
        for z=0,1024,64 do
            line(z,0,z,512)
        end
        for z=0,512,32 do
            line(0,z,1024,z)
        end
        setContext() 
        -- end test texture  
    
        level=5     --  0 thru 5
        flat=false  -- true (triangles) or false (rounded)
        insideView=true -- show inside view of sphere
    
        assert(craft, "Please include Craft as a dependency")
        assert(OrbitViewer, "Please include Cameras (not Camera) as a dependency")        
        scene = craft.scene()
        v=scene.camera:add(OrbitViewer, vec3(0,0,0), 350, 0, 600)
        createSphere()
    end
    
    function draw()
        update(DeltaTime)
        scene:draw()
        sprite(myImg,WIDTH*.85,100,300)
    end
    
    function update(dt)
        scene:update(dt)
        sph.rotation = quat.eulerAngles(-90,0,0)
    end
    
    function createSphere()
        sph=scene:entity()
        sph.position=vec3(0,0,0)
        sph.model = craft.model.icosphere(100,level,flat)
        sph.material = craft.material("Materials:Standard")    
        sph.material.map=myImg 
    
        local seam=0
        local ax,bx,cx,ay,by,cy,c,lat,lon  
        local posTab=sph.model.positions
        local pTab,cTab,nTab,llTab,uvTab,colTab,norTab,iTab={},{},{},{},{},{},{},{}
        local deg=math.deg
        local asin=math.asin
        local atan2=math.atan2
    
        -- create tables for rounded icospheres        
        if not flat then
            iTab=sph.model.indices
            pTab=sph.model.positions
            cTab=sph.model.colors
            nTab=sph.model.normals  
            for a,b in pairs(iTab) do
                posTab[a]=pTab[b]
                colTab[a]=cTab[b]
                norTab[a]=nTab[b]
                iTab[a]=a
            end
        end 
    
        -- convert sphere positions to latitude and longitude
        for a,b in pairs(posTab) do
            c=b:normalize()
            lat=deg(asin(c.z))+90
            lon=deg(atan2(c.y,c.x))
            llTab[a]=vec2(lon,lat)     -- save lon, lat in table
            if lon//1==-149 then    -- get exact value of seam
                seam=lon
            end
        end  
    
        -- shift points on the left side of the seam to the right side 
        for a,b in pairs(llTab) do        
            b.x=b.x-seam
            if b.x<-.01 then
                b.x=b.x+360
            end
        end 
    
        -- shift individual points of triangle if needed  
        for z=1,#llTab,3 do
            ax,ay=llTab[z].x,llTab[z].y
            bx,by=llTab[z+1].x,llTab[z+1].y
            cx,cy=llTab[z+2].x,llTab[z+2].y
            if ax>250 or bx>250 or cx>250 then
                if ax<.01 then 
                    ax=360
                end
                if bx<.01 then
                    bx=360
                end
                if cx<.01 then
                    cx=360
                end  
            end  
            if ay==0 or ay==180 then
                ax=(bx+cx)*.5
            elseif by==0 or by==180 then
                bx=(ax+cx)*.5
            elseif cy==0 or cy==180 then
                cx=(ax+bx)*.5
            end  
    
            -- create uv table
            uvTab[z]=vec2(ax/360,ay/180)
            uvTab[z+1]=vec2(bx/360,by/180)
            uvTab[z+2]=vec2(cx/360,cy/180)
        end  
    
        -- reset tables 
        sph.model.uvs=uvTab 
        if not flat then
            sph.model.indices=iTab
            sph.model.positions=posTab
            sph.model.colors=colTab
            sph.model.normals=norTab
        end
    
        --update indices table for inside view    
        if insideView then
            iTab=sph.model.indices
            for z=#sph.model.indices,1,-1 do
                iTab[#iTab+1]=iTab[z]
            end
            sph.model.indices=iTab
        end
    end
    
  • dave1707dave1707 Mod
    Posts: 9,287

    @Bri_G How does the above code at level 5 flat=false look when using your Earth texture. I tried using some Earth images, but I haven’t found any images that were very good to start with. I believe the above code textures everything as good as it can be textured.

  • edited April 2018 Posts: 2,270
    @dave1707 - sorry I didn't comment straight away, trying to put Sokoban in Codea. Sphere looks fine to me I'm using a reduced image from

    https://visibleearth.nasa.gov/view.php?id=57730

    At 1024 x 512.

    Try it yourself.
  • dave1707dave1707 Mod
    Posts: 9,287

    @Bri_G Thanks for the link. Those images had too much ice at the top and bottom, but that lead me to this link. I used the 5400x2700 at 14MB.

    https://visibleearth.nasa.gov/view.php?id=73751
    
  • edited April 2018 Posts: 2,270

    @dave1707 - thanks for the link, checked the hi-res one you downloaded, I tend to use 1024x512 res for most things. Very good speed and quality, are you sure about the ice/snow?

  • dave1707dave1707 Mod
    Posts: 9,287

    @Bri_G This was the image I used from your link. There was too much white at the top and bottom of the image. Maybe it wasn’t the one you used because I didn’t see a 1024x512 size.

    https://eoimages.gsfc.nasa.gov/images/imagerecords/57000/57730/land_ocean_ice_2048.jpg
    
  • Posts: 2,270

    @dave1707 - I reduced an image from 2048x1024 to 1024x512. I have a number of these, some from JMV38 to show night and day. The difference seems to be around the North Pole. There seems to be sea all across the top of your image, I assume it depends where the satellite taking it the image was located relative to the equator.

  • dave1707dave1707 Mod
    Posts: 9,287

    @Bri_G The picture I found was taken in I think August. There were a bunch of pictures taken at different months, so the amount of ice/snow was different. I picked one with the least amount of ice/snow so the North Pole wasn’t all white.

Sign In or Register to comment.