@Xavier Thank your for your update. It seems that we have a small Blender here. I look forward to seeing your update.
Well, Here is a small video to show the current progress:
http://www.youtube.com/watch?v=S3n-7irqpbw
Texturing is a lot of fun 
I really wish I could find a way to make it generate faster in high resolution… But apart from using magic, I don’t think I really can 
I’ll update the code once it’s commented
/cheers
Well… I’ll be damned ^^
I said I couldn’t make it generate the textures much faster, I was so wrong… Optimized the function as much as I could and boom, textures are generated 4 times faster !
I wish there was a clamp(x) function… min(1, max(0, x)) is so ugly 
Code updated for now, I’m going to go see what else I can do
Cheers,
Xavier
Like it! Something worth putting Xavier in the beta 
@Xavier I’m sure you’ve already done this. If not — write it as a function?
function clamp( x, min, max )
return math.min( max, math.max( min, x ) )
end
Though it would be a good thing for us to add. I’m not sure if we should start modifying Lua’s internal math library. Adding it outside of math.* seems inconsistent.
@simeon - Oh I wasn’t even thinking about asking for a clamp function, I was just stating that - takes a deep breath - mycodelooksuglybutIhavenochoicegrrrmybrainisdead
I briefly considered using a custom function, but figured there would be just enough overhead to make me realize how much I should appreciate my code…
Actually, the only things I miss are built-in vec3 and matrix functions, but you already stated it was planned 
Anyway, going back to coding… after I browse the forums for cool stuff
big hugs to http://www.lua.org/gems/sample.pdf
Xavier
edit - wohoo gained another 4 fps in quality 2 this post needs more smileys 
;(
Interesting document on Lua optimisation.
I’m adding the vec3 and matrix features to the issue tracker so I remember to add them.
@Simeon thanks! Codea will be even more 3D ready
I have a question… In my program, I loop through my model on touch so I can translate raw vertices (no choice when using sphere trick).
When using max quality, I go through the 4225 points of my model, but I’m running into a weird issue.
When sphere transformation is active, this line gets included in the loop:
v.y = v.y - (v.x * v.x + v.z * v.z)*0.001.
What happens is that the draw function won’t be called until touch has ended (although it’s running at like 12fps). I therefore cannot see my sphere rotate on touch
When sphere transformation is disabled however, the draw function gets called properly and I can see model translate on screen as I touch it.
Do you have any idea what that means ? Here is the code:
local vs = mdl.vertices
for i=1, #vs do
local v = vs[i]
local vx = v.x
local vz = v.z
-- restore the shape of the model (turn it from pseudo-sphere to simple heightmap)
if sphere == 1 then
v.y = v.y - (vx * vx + vz * vz)*0.001
end
-- due to the way the trick works, translating the vertices rotates the "planet"
v.x = vx + deltaX
v.z = vz + deltaY
v.y = v.y + delta
-- once the translation work is done, turn it back into a pseudo-sphere
if sphere == 1 then
vx = v.x
vz = v.z
v.y = v.y + (vx * vx + vz * vz)*0.001
end
v.done = false
end
Apart from that, I think I’m done optimizing the code (well I always say that).
I’m now getting 36 fps in quality 2, that’s 4096 textured polygons or 12 288 vertices
I got that final speed boost optimizing loops and getting rid of the table.insert (now using premade arrays at the correct size).
Before I started optimizing, It wasn’t running above 1.5 fps at that setting without textures…
Anyway, source is updated.
I think I can start making a game out of it, and since it won’t need anywhere near that polygon count, that leaves a LOT of room for physics and cool stuff
Thanks again for making such a cool app!
Cheers,
Xavier
@Andrew_Stacey - I’m actually going to implement what you suggested for zsorting.
Right now I’m sorting every few frames even when it’s not needed.
You’re right that if I make it so it only happens on rotations (every few frames), and initialisation, I’ll be more efficient
Thanks again for your help and suggestions !
Hey all,
I’ve implemented textures, and imo it looks pretty damn great. Can’t believe I made this entirely on my old iPad… Codea is making my ego skyrocket right now
For now the textures are obviously generated so it’s somewhat slow to load, and i’m not great at it. Results will be even better when Codea adds an image upload
Here are some screenshots:
http://i42.tinypic.com/b9ghw5.png
http://i41.tinypic.com/90vchz.png
http://i44.tinypic.com/1zbdyxk.png
Well it’s 6 in the morning, time to sleep…
Xavier
Wow - those screens look amazing, @Xavier.
I’ve added the operator support to vec3. This is our thought for the 3D API, would this help you at all?
- vec3, vec4 and matrix types
- Support for vec3 * matrix, vec4 * matrix operations
- Update mesh() to use 3D vertices (vec3)
- Add applyMatrix(m) and loadMatrix(m) functions. These multiply the given matrix against the current transform matrix.
@Simeon,
It would be great if you could also implement a fast routine to transform 3D coordinates to 2D screen pixels. This is something needed all the time when dealing with 3D. If you could also implement a routine to detect hidden lines, that would be great.
@Simeon: Please, don’t forget the 2D things. Codea still lacks many things on 2D space. Don’t let this 3D guys distract you. For example… more 2D shapes (round rectangle, arc, pie, polygon, flood fill, outlined text, etc) and API for gestures.
@CrazyEd — Codea actually renders in 3D natively. So by simply giving mesh the ability to use 3D vertices, and the user the ability to load an arbitrary transformation matrix (such as perspective) the 3D → Screen transform will happen via OpenGL.
@bee we won’t forget about 2D stuff. 3D is relatively simple to implement at the basic level, so it’s easy for us to do. This is because Codea is already rendering with OpenGL.
Thank you, @simeon. Please, provide polygon and floodfill on the next update. It’s because physics engine already supports polygon object but the drawing API doesn’t support it.
Thanks, @Simeon. That sounds very good. Then I will continue updating my 3D math code …
@bee the mesh() class allows for arbitrary polygons to be created quite easily. You need to use triangulate() to generate the triangles, then dump them into a mesh to render a polygon. In fact, the initial reason mesh() was added was to support drawing the polygonal bodies used in the physics engine.
I’m a bit lost on how floodfill would work — do you mean for images? Something like image:floodfill( x, y, color [, tolerance] )?
@simeon: I thought mesh() is only able to create polygon with numbers of side are multiple of 3, no? How to define its stroke color? and the fill color? I haven’t play with mesh() myself yet. I’ll take a look its capability. Thank you for the hint. About floodfill, yes that’s the way I thought it should work. But it could also work on screen as well.
@bee flood fill is not technically possible on the screen. But you could use the image variety by rendering into an image and then using flood fill on the image.
Mesh can create any polygon, however the polygon must be broken into triangles. The triangulate() function does this. Mesh respects the current fill colour unless you set colours for individual vertices, which then get blended across the mesh.
Mesh can also be filled with an image by setting its texture property and assigning texture coordinates to each vertex. The image will be multiplied against the fill or vertex colours, in the same way that tint() modifies a sprite.
Mesh doesn’t support a stroke, however this can be solved at the moment by rendering lines around the perimeter of the mesh.