If it’s text assets you can delete them in the asset picker (press “edit” in the top right corner of the pane, select the files you want to delete). But it seems it’s a bug that saveText nil doesn’t work. It works for the globalData, projectdata commands, and according to the reference, it should also work for saveText. Perhaps we should file a bug report in the issue tracker.
You can access assets using the Lua io library, but the io.remove command (which is how you would delete a file) has been removed from Codea (presumably to meet Apple’s requirements, as you could do some serious damage). io.write doesn’t except a nil value either. oops, typed in the wrong command. Its os.remove, not io, and it is present in Codea. It doesn’t seem to delete the file as such, though, just deletes its contents (presumably the same as writing an empty “” string).
If you want to experiment, here is how you use the io library to access files in the Documents folder.
local path = os.getenv("HOME").."/Documents/"
local file = path..fileName --unlike readText etc, with io library, path needs to include extension
local data = file:read("*all")
file:close() --not sure if this is necessary. Probably a good idea
Not sure if this really gives you any useful options vs just using readText.
In theory it should also be possible to access files in Dropbox in this way. Does anyone know the path for Dropbox assets in Codea? (the app I used to use to examine file structure, iFunBox, doesn’t seem to be able to look inside apps’ structure from iOS 8.3. Is this the same with iExplorer? Perhaps someone who is still on iOS 7 could take a look?)
SaveText does work, just not for deleting. But it’s easier to delete text assets in the asset picker, no? I don’t believe it’s possible to add paths to global, project, and local data.
We just need to work out the path for Dropbox. According to the Codea wiki, section Under the Hood, Dropbox images are in HOME/Documents/Dropbox.spritepack/ . But the page hasn’t been updated since the text assets feature was added, so it doesn’t say what the path for Dropbox text files is. I’ve tried HOME/Dropbox/ , HOME/Documents/Dropbox, HOME/Documents/Dropbox.textpack/ HOME/Documents/Dropbox.text/ etc.
If someone with a pre-iOS 8.3 device and iExplorer/ iFunBox (or a jail broken iPad) or whatever could check what the path is for Dropbox text assets, I’d be really grateful.
I’ve been doing some more experiments, and one big advantage of using text assets (ie readText saveText) for things like 3D models, if anyone is thinking of going the XCode/ AppStore route, is that they automatically get exported with your project, whereas global data/ project data isn’t.
btw, one slightly odd behaviour I’ve noticed as that when you create a file with saveText it doesn’t always appear straight away in the asset picker in your project. At first I thought the old “save text can’t create new files” bug had appeared again, but the files are there, it just sometimes takes a while for them to show up. If you exit the project and look in the general asset viewer you can see them, and then when you go back into the project they’re there. Just thought I’d post in case it’s confusing anyone else.
@dave1707@UberGoober more testing… using io.open and io.read on Dropbox files in HOME/Documents/Dropbox.assetpack works for text files with extensions other than .txt. You can’t see or select the files in the asset-picker, or load them with readText, and they won’t be automatically exported as assets when you export the project. But you can read the files in Codea with io.open and io.read (and of course you can see, rename, delete etc the files in Dropbox). This is actually pretty cool, as it gives you an option to easily bring data into Codea (and manage it with Dropbox), but without cluttering up your asset pickers.
Slightly off-topic, but my current thinking is (I’m going to write a blog post on this eventually, in the series on keyframe interpolation of Blender models) that I want an interim 3D format. The reason why is that when you have a project with lots of models, string.gmatch iterating over several long .obj files every time you launch the programs takes time (in one of my 3D projects, the launch time is already around 6 seconds, and I’m only half way through adding models).
What I’m planning on doing is having a separate model loader program that loads the models, parses the .obj files, and then saves the tables of vertices, texCoords, colours etc as json strings with saveText (by adding the __tojson metamethod to vec2, vec3, and color). This would pack all of the animation frames into a single text asset that you could select in the asset picker of the main program, and that could be unpacked into a mesh very quickly, and would automatically be exported as an asset.
This means you could keep most of the file i/o and string parsing out of the main program (and the source files, the .obj, .mtl files etc would stay hidden in Dropbox). The resulting text asset would take up more space than the .obj files (because it describes every vertex in the mesh, not just the unique vertices, as .obj files do), but I’ve been experimenting with different ways of encoding the vec2s & vec3s in the json string and I think I’ve got it so that the resulting files are less than twice the size of the .obj files, which is a worthwhile trade-off for how much faster the app startup time would be, and how much simpler loading a model would be in the main program.
From my observation, obj files do include every vertex in the mesh, they come in sets of three (or four), like this
v -2.328231 -0.889590 -3.267325
v -2.301960 -0.868956 -3.298030
and in the case of this file, each of these vertices appears twice.
wrt compressing the data, simply dropping less significant digits would make a huge difference to size, I imagine. Our models don’t need too much precision.
JSON is also very verbose. It would be a lot more compact to simply concatenate the vertices with a delimiter, and use a split function to put them into a table. If you’d like me to do some testing, I’m happy to help.
In the .obj file the lines beginning “v” describe unique points, and the lines beginning “f” wind those points into triangles, avoiding describing the same point twice. I just did a quick check with some obj files, and couldn’t find any duplicate points in the lines beginning with “v”.
In the interests of load-speed and simplicity, my format is a dump of the vertices that will be applied to mesh.vertices, so would include duplicate points.
Good point about rounding the figures. Your .obj importer already rounds to 2 decimal places, and the json encoder detects this and lops off the unneeded zeroes. This is actually probably why the json file is as small as it is. I’d forgotten that your .obj importer did this until you mentioned it.
If you’re writing your own __tojson metamethod, then json can be as verbose or as minimal as you want it to be. Because the table is homogenous, I’m just putting an identifier at the head, and then each vert is just a three part array. This is what the start of the file looks like:
actually, you’re right, now I remember how it works (it’s been a while)
Why not just string them all together without any square brackets, because they have to be packaged into vertices in threes at the end anyway? In other words, are square brackets necessary when the format is so simple?
@yojimbo2000 When I gave you the path to a file, I should have mentioned that you could read and write to any extension even though you can’t see them. I mentioned that maybe a year or 2 ago when I was posting examples about reading and writing files with io commands.
Yeah, I figured none of this is new knowledge. I’d been searching the forum for Readtext examples but I hadn’t got round to searching for the io functions. I guess I’ve neglected IO. I’ve just relied on global/project data, but actually text assets, plus io actions on Dropbox, are far more suitable for what I’m trying to do. Thanks again for bringing this to my attention.
I just did a quick test of my new Blender workflow and it works perfectly. Save straight to Dropbox, no need to manipulate/ edit the files in any way, load them straight into Codea with io.read, no need for an asynchronous loading class/ methods etc. This is a much, much faster workflow than what I was doing before, and is really going to speed up 3d development. I guess that’ll teach me to neglect io.
I’ll post my version of the importer when it’s ready.
Wow, lotta talkin’! As for my project, I’m still struggling with abstracting the obj loader so I can see my model. @yojimbo2000, thanks for the Dropbox investigations. You also wrote:
Its os.remove, not io, and it is present in Codea. It doesn’t seem to delete the file as such, though, just deletes its contents (presumably the same as writing an empty “” string).
…have you found out anything more about that? Is there a way to actually delete the file “for reals”?
get a female 3D model from MakeHuman in a long-sleeved dress and pants
get that model into Codea via the .obj importer
make the meshes for the clothes use a local image resource for texture
get the top meshes to treat an alpha value of 0 as an actual transparency, so we can make the shirt and pants look shorter just by erasing that area on the texture file
skip the whole “image editing UI” thing and just have the file on Dropbox, and edit it with an external image editor
Along the way, #3 just happened naturally – didn’t need the .ply importer to do textures after all.
And as it happens, #5 is also just a natural by-product of #2. Once the model’s reading textures off of Dropbox, any edit to them naturally appears on the actual render the next time the project launches.
Like so! If I make a big orange spot on the jeans:
@Ignatz, @Yojimbo2000, any advice? I’ve kept my head above water so far, but I am wayyyyy out of my depth on this here. I don’t even know where to start. How do I figure out how to make a mesh treat transparency on its texture as actual transparency?
In the fragment shader, whatever variable that gl_FragColor is being set to, do something like this:
col.a = pixel.a; // where pixel is the texture sampler2D value. ie final alpha is determined just by texture color, and not by lighting etc
gl_FragColor = col;
the texture will need to be imported into Codea as a png (as jpegs don’t have alpha), which AFAIR means not via the camera roll, and the clothing mesh has to be drawn after the human mesh.
I think you will find setting col.a=0 doesn’t work properly. I have been creating explosions which become transparent. I spent some time fading the alpha value down to zero in the shader without result before realising I had to fade r,g,b as well. In other words to create transparency gradually, you need something like this