MyAmuseVoxel: a voxel editor based on the built-in sample(Voxel Editor)

Code Sharing
21

Would it be correct to assume that spriteSize is not the only code that will be affected by this?

Correct

What it is

It’s not specific to Air Code, but it is specific to iOS and interacting with the wider filesystem. Basically, a while back we added support for external folder references where you could import a folder somewhere on your filesystem

This meant you could access assets in those folders by using asset.ExternalFolderName.FileName

The thing is, those files might be in use by other applications when Codea attempts to read them. When you use file coordination, a message is sent to other applications which have the file open that they should save their changes. This allows Codea to read the latest version of the file

Similarly, when Codea attempts to write to such a file, this tells other applications watching that file that they may want to reload the data

A simple example might be that you update an image file on your Mac in iCloud and expect Codea to pull the latest version of the file when you run your project

Performance cost

For something like spriteSize or sprite, we implement caches so that once they are loaded the first time, subsequent reads simply return the cached asset. We’re going to have to decide to cache on a case-by-case basis, going by the following tradeoff: is this something likely to be called in draw? Or is it something the someone will want to edit externally and expect the latest version of?

It has been great to know where you have hit performance issues, please keep telling us and we will be able to make better decisions about what parts of the API likely need asset caching and which parts do not

22

Personally I have no problem with the constraint of needing to have a file in the project itself or in the Codea folder for a project to reference it.

I wonder how many people, if given the option, would prefer external file access over fast access to local files. Fast access to local files seems far more important to me.

Personally I’d prefer that files only be accessible from inside a project. This comes from many many experiences downloading other people’s projects only to find they won’t run without this file here and the other file there and another file in the other place.

Looking at other people’s work is the primary way I learn how to do new things in Codea and it would be extremely helpful if I never had to worry about missing assets again.

I also like to think about how things affect new users, and I may be wrong but my hunch is that accessing external files is very far up on the learning curve for users. I’d bet accessing local files is very low down on that curve. I’d think the trade-off has to be weighted toward what will be more of a PITA for people new to Codea.

As to project use: I might be wrong but I think all the voxel editors use file access for undo/redo functionality, which would slow down every single action done with the editor. My SimpleButtons write and read from tabs every time a user moves a button—would that be affected? My Craft scene creator has to access local assets every time someone wants to add an asset.

I don’t know exactly which of my old projects will be affected by this but I’ll tell you this for sure: I don’t look forward to finding out.

It’s going to be a rude surprise every time I open an old project—mine or someone else’s—and remember that the code won’t work anymore unless I go poke through the code and account for this.

It just seems like a really radical choice to make, affecting all asset access, for the sake of something I personally—a user since around 2012–have never done, wanted, or needed. The universe doesn’t revolve around me, of course, but were I you I’d want some data on the issue and who it will affect and how often.

One can never be 100% sure of anything, but I can literally guarantee you not every consistent user accesses external files—because I don’t. OTOH I can practically guarantee you every consistent user of Codea does regularly access local files.

EDIT I also am curious how external file access affects exporting a project to XCode—one of the primary draws of Codea. I’d be quite surprised if it isn’t far easier to export a local-files-only project than a project with files scattered everywhere.

And does that mean XCode projects would actually run faster than Codea projects because they don’t have to account for file-access conflicts?

23

The requirements to run the project—the need to make a specific folder and include specific dependencies—can be detected and printed to screen without crashing, I think.

If an average user downloads your project, and runs it, and it crashes, they’re unlikely to run it ever again, in my estimation.

If you intend this for general use, it would be very helpful to keep the program from crashing at all costs, and instead and show the users a blank screen with text describing how to fix these issues.

24

@UberGoober - I have a view on this which might not be popular but I feel could be adaptable for any user. So I’'ll spell it out:

The advantages of having assets in a local folder are the ideal situation, but the cost on memory usage may, in some cases, demand good management to enable flexible/best use of iPad memory.

So, one possible way forward is for Codea to set up a local folder to download assets to giving it an ID and providing an option to the programmer to retain (and possibly rename) the assets folder if required. If not retained Codea deletes temporary folders when it closes.

Further, I think when exporting a project, the option to include assets should be presented to enable programmers to pass on the final zipped project or to not include them to enable zipped retention of just the code assets at each development stage.

Of course this would entail Codea being able to replace the relevant asset paths in the code as required during development and in closing projects.

That should satisfy the needs of the project developers.

Is this feasible ?

25

Great feedback! I share your worries about performance and I am looking into whether we can support an API that allows you to disable file coordination for specific asset folders (eg: asset.localAccessOnly = true)

That said, I would rather start from a baseline of correctness, and improve performance from there. Why?

Codea 3.11 introduces iCloud Drive support. I am using it personally to edit the same projects on my iPhone and iPad. I even shared one for collaboration via an iCloud link and other users could update my project. This isn’t an advanced feature, and we should get it right before we get it fast. It may even become the default new project storage location once we get it stable and tested

So you can see why there is a desire to make sure undefined behaviour is eliminated when running projects. Accessing files unsafely may fail to trigger updates for others, fail to load or render assets, and worst, work correctly but you don’t know why because it didn’t work yesterday

However some of the use cases you pointed out are important! Like storing UI preferences, reading and saving stuff that shouldn’t be shared with the project and is really “session” data. Perhaps we need an asset.local.* API for fast access to data that is not ever coordinated with the system?

Happy to hear your thoughts!

26

Letting multiple people live edit the same project? I can’t imagine what that does to versioning efforts. Only half in jest here: are you trying to drive git users insane? I’m no power git user so maybe I don’t know what I’m talking about. Or have you maybe thought two steps ahead and this is also somehow combined with versioning?

27

It’s not combined with versioning, and it really is just a side effect of if you support iCloud, you can share iCloud documents with other people and they can edit them. The best use case right now is that you can edit your projects across all your devices

At the moment the merge strategy is very basic, but we could potentially show a diff view and do other cool things down the line if we wanted to

Screenshot 2024-04-01 at 21.10.38
Screenshot 2024-04-01 at 21.10.381179×2556 194 KB

1 Like
28

But back to MyAmuseVoxel: @binaryblues does it still require downgrading Codea to use it?

29

The original version (MyAmuseVoxel 007, I think) was fixed in my testing when we fixed spriteSize so that it returned cached values on subsequent calls. This came out in a later version of Codea 3.10.1

And the fix I suggested to @binaryblues was also implemented in MyAmuseVoxel 008, which fixed the performance even on earlier betas of Codea 3.10.1

30

@UberGoober There’s no need to revert to a previous version, as I have manually implemented caching in the code according to the solution provided by @sim . You can simply download the project link from this post(I have kept my updates in sync with WebRepo) and use it. Alternatively, you can download the last version V009 from the WebRepo.

Also, I have just tested the latest Codea update and found that Codea now offers built-in caching, so the lag issue caused by caching should be resolved.
Additionally, the issue with the x parameter in volume:resize() has also been fixed. The startup time of the program has increased.

Balancing stability and efficiency may require multiple iterations of adjustment and testing in order to find the most suitable point.

I am very grateful for the hard work of @sim and @John.

1 Like
31

I finally got this working by downloading it from the forum here. Getting it from WebRepo never worked. Even when I created the necessary folder I got errors about missing assets.

The visual model loading UI is fierce!

1 Like
32

@UberGoober I also find it quite strange that the projects posted in this thread are versions modified by WebRepo. In theory, they should be exactly the same as those installed directly from WebRepo.

The visualization model loading uses code from the built-in example projects, with some extensions made on the basis of the original code. The example projects have a well-structured code architecture and excellent extensibility. Using them as the foundation for code can save a lot of time. Moreover, studying and learning the specific details of their implementation can also help deepen the understanding of Codea’s APIs.