@Bri_G - unfortunately all internet transfers are asynchronous in Codea, so the problem isn’t with where the data is kept on the internet, but with the fact that your code has to pause itself while the data is being retrieved, not just once for the obj file, but also for each texture image.
I think I have it working now, anyway.
I also have the code in a class, allowing loading of multiple models. I’ll modify it so it doesn’t need an mtl section (in what is now a combined mtl and obj file). But if there are texture images, then you will need an mtl section to assign each image to the correct material.
The spitfire is magnificent, but the Merc is a mess, for some reason.
It now loads a model into a class, but can’t load more than one at a time, yet.
If you open one of the urls in the Assets tab, you’ll see the data layout. Essentially the mtl comes first, then a [obj] tag, then the obj file. Note the way images are defined in the mtl section
It should work without an mtl section, but I haven’t tested that.
I’ve started thinking about how to fly these models…
Loaded up and ran - superb, Spitfire is really well detailed and the rest of the models (except Merc) are great. Have you solved your flickering problem? As I say one of the early models showed it - probably the first one that you ran - a sort of ring spaceship with engines attached. Flickering occurred in the engine vents.
Will digest your file format next - is this an Ignatz home grown? Have you just combined the .obj and .mtl? The literature suggested .mtl is being phased out and variants now being used as alternatives - probably like your own file.
Last phrase, not sure - if you mean on screen - fine!! Otherwise we’ll start to worry about the amount of time you are putting in to this - do you actually get any sleep?
I think there is something in the air down there - my old boss moved down to New Zealand and he spent most of his time flying model aircraft, driven by rubber bands. I spent many hours developing software for him so that he could change his designs to get longer flight times. He even went to the underground salt mines in Poland (or maybe Russia) for global competitions - even won awards!!! For me - doing it on a computer/pad is good enough.
Be in touch when I’ve tried my models out on your viewer.
@Bri_G - my single file is simply the mtl file followed by the obj file, with a separator tag [obj] (on its own line) which goes between them.
I haven’t solved the flickering. Unless the artists made mistakes, it’s probably to do with the way I calculate triangles for faces with more than three vertices, because that is the only adjustment I make to any of the data provided.
Andrew Stacey is going to help me to actually fly these planes around in Codea. It involves quaternions, which I just cannot understand.
Checked out your files and it makes sense. Andrew’s your man when it comes to matrix maths - he has written an article about it on his web-site. I’m interested in learning how it’s done - I’d like to take models and put them through a figure of 8 loop flying into the screen from behind the camera and then flying back looping as they go. Andrew wrote the example for Codea (main panel) with 3D scrolling around a series of what look like steps or wooden beams - could possibly start to look there for the movement suggestions.
@Ignatz - you’ll probably find a fair number of the free models on the web have some sort of anomaly - so I wouldnt be too concerned when testing your code. Often some (or all!) of the normals being flipped is quite common, especially if they’ve been converted from another format, as well as badly laid out or overlapping texture co-ords which is another modeling no no and can cause rendering issues.
With my .obj importer I got round this by cleaning up the geo first in Maya and also pre-tesselating any quads or n-gons first, so I then have only a clean, consistent set of triangles with outwardly facing normals to deal with prior to exporting the .obj. This makes everything a lot more predictable and simple when parsing the file and testing.
Other ‘gotchas’ with 3d models are:
Co-incident polys in the same place - the number one cause of flickering polygons, as the renderer cant work out which one is in front of the other.
Dangling vertices or edges - edges or vertices not associated with any polys.
A poly with collapsed vertices - a valid poly, but all the vertices are the same yielding to zero area and an apparently ‘invisible’ poly.
Non-manifold geometry - three or more polys share an edge. Generally bad modeling practice and can cause renderers (and certain poly operations) to fail.
You might want to look at these should any of your models yield odd results with your importer…
@andymac3d - thanks for that. I’ll go back and look at the models in Blender.
Looking at your point 4 above, reminds me that when there is a face with more than three points, I need to break it into triangles, so I calculate the average vertex centre and make triangles with that point and every adjacent pair of points. This means the centre point can be shared between many triangles.
Is there a better way to subdivide a large polygon?
@Ignatz - the danger with this method is it works fine for a convex polygon, but if you have something thats concave (imagine a pacman type shape made up of say 8 vertices) then making an assumption you can find the mid point and tesselate from there quickly falls apart as you start getting overlapping polygons (see point 1 on my list!).
I think my point is that its fairly difficult to accommodate every possible scenario of the sorts of polygons/models your importer is going to encounter. Much easier perhaps to assume (as I have) that any model should be composed of triangles and let your 3D package do the ‘heavy lifting’ in respect to cleanup and tesselation.
Here is my 3D lunar lander game, with a model of the actual Apollo lander, both in flight and on the ground after landing. This game is now a combined hack of several different projects I’ve worked on in the last 6 months!
(as always, the video is murkier and less clear than the original).
The video is bl#!dy marvelous, particularly the 3D walk on the moon’s surface. Bet that’s whats soaking up your FPS. The curvature on the surface is very realistic.
Here is an updated video of my spitfire flying (floating, rather) in a sky consisting of (the inside of) a sphere with a sky image mapped to it, so it provides a 360 degree sandpit to play in (once I can fly the plane).
The spitfire turns as the iPad is tilted, and the (genuine Spitfire) sound is a beta Codea feature.
I still have to learn to create flight controls (and manage the rotations involved), and Andrew Stacey is helping me with that.
If anyone likes simulating real world stuff and would like to get involved in making this more realistic, let me know. My interest is mainly in the graphic part.
)