@Simeon - @John
Can someone refresh my memory - I recollect going through a whole series of sphere mapping alternatives to the one used in Craft some great work by forum members to create excellent detailed images. What I can’t remember was if we incorporated any learning in the Craft icosphere model. My reason being I just set up a textured sphere and tried a few images to check it out and found each sphere had a zip (see attached image). Do we need to add a new model or do I need better textures?
@Bri_G, yes, i think the native Codea icosphere is not correct. I therefore use the @LoopSpace version which is better. Someday i hope @John will fix that. I guess the sphere used in Shade is correct?
@Bri_G Here’s my version that I posted long ago. You can also zoom in to see the sphere from the inside.
PS. I found the original link where I was creating the code.
https://codea.io/talk/discussion/9133/craft-sphere-texture#latest
displayMode(FULLSCREEN)
function setup()
assert(OrbitViewer, "Please include Cameras (not Camera) as a dependency")
scene = craft.scene()
v=scene.camera:add(OrbitViewer, vec3(0,0,0), 700, 0, 1000)
myImg=readImage(asset.builtin.Surfaces.Basic_Bricks_Color)
s1=createSphere(vec3(0,0,0),200,5,false,true,myImg)
end
function draw()
update(DeltaTime)
scene:draw()
end
function update(dt)
scene:update(dt)
s1.rotation = quat.eulerAngles(-90,0,0)
end
function createSphere(pos,size,level,flat,ins,image)
local s=scene:entity()
s.position=vec3(0,0,0)
s.model = craft.model.icosphere(size,level,flat)
s.material = craft.material(asset.builtin.Materials.Standard)
icoTexture(s,ins,image)
return s
end
function icoTexture(sph,inside,img)
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
sph.material.map=img
-- 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 inside 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
@piinthesky @dave1707 - thanks for that, confirmed my own recollection. I remember @LoopSpace tried a lot of different approaches shame we didn’'t get an upgrade there. The Shade version does look to be complete, as you say, and should be transferable. In the meantime anyone know what the possible problems are in using sprites, meshes and Craft together?
P.s. @dave1707 - thanks for the link and code, I need to re-read that to get back up to speed.
@dave1707 - simple idea, raised this thread again ‘cos I thought we may be able to improve on this issue. Not modifying the code as such, as it works fine, - no, my suggestion is to take the code, build the model and write it out as a file - an obj file. Then we can simply load it in one line of code. What do you think?
@Bri_G All the info is in the tables (indices, positions, uvs, etc.). It would be just a matter of converting them to an obj format. That might be the sticky part.
@Bri_G I can create an obj file, but so far it’s not displaying anything when I use it. I’m still trying to figure out what’s going wrong.
@dave1707 - started looking at your project but, you know what it’s like somebody else’s code. Then I printed out the number of vertices, just less than 128,000.
At that point I thought simplify, build crude one that works - then print out the obj file. Finally scale up to mid poly at least. So I’ve gone back to first principles and looking at ways to build up a sphere.
Found a few interesting articles, and started to investigate sphere from a cube.
In parallel also looking for free sphere obj model to get the display program working.
Not much progress yet - if you want to post your obj file I’ll check it out and see if I can find any flaws.
@Bri_G I was able to create the obj file for the icosphere. The only problem is the size. For a level 1, the obj file was 23,805 bytes. For level 2, 103,275. For level 3, 443,511. And level 4 was 1,850,847. It took what seemed like 5 minutes to create the level 4 file.
PS. The file doesn’t contain the normals yet. I was going to put a zip file with the demo, but it doesn’t work right if I put the obj file in the project folder.
@dave1707 - creating the file isn’t the issue, how quickly does it load into Craft? I wouldn’t worry too much about the normals.
@Bri_G I was able to add the normals to the file and get it to work with the project folder. Here’s the example for a level 1 icosphere. The obj file is a little bigger with the normals added.
@fave1707 - that’s great. Loads up very quickly. Did you say this was level 4? I thought the face size would be smaller. I think when we look at the number of vertices involved and the time to create them we expect it to be smoother.
I found a sphere obj file on the net will post a zip to you shortly. I’m just looking at texturing it.
@Bri_G It was a level 1. I mentioned that above even though the project is 004. A level 3 loads in less than 3 seconds and the obj is 645,753 bytes.
@Bri_G I haven’t tried your file yet. I don’t like my obj files because of the size for the higher level spheres. Also, the north and south poles of the sphere aren’t north and south, but on the equator. So the rotation doesn’t work right. What I did instead was make my createSphere program as a dependency. It can create a level 6 icosphere in less than a second and because it’s a dependency doesn’t show up as lines of code.
I’ll try your sphere file later.
@Bri_G Was able to use your file, less than a second to load. It looks like it’s between a level 1 and level 2 icosphere.
@dave1707 - yeah, deliberately playing with low poly so easier to handle but still a lot of lines in the file. Never thought about the sphere as a dependency. I’ve done that for lots of small low poly models in the past - should have thought about it before. Just going to look at options for sphere code now to see if I can find the best option. Dig through the old forum notes.
@Bri_G I gave up with the obj file. They’re too big for higher level icospheres. I changed my texture program so it can be used as a dependency (IcoCreate). Here’s the IcoCreate to be used as the dependency and IcoDemo that uses it.
Edit: The dependency file IcoCreate.zip was removed and updated below.