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

[binaryblues]

This is a project based on the built-in example project, Voxel Editor.

Specifically, it adds several features to the original project, including:

• model editing capabilities (which is the core functionality of the original project),
• a user interface (UI) that conveniently adjusts sizes to fit different screens,
• the ability to save and load models, You can select the model to be loaded through the thumbnails in the model list panel.
• the option to freely name models,
• the capability to slice the model along the XYZ axes at any scale to facilitate the editing of the model’s interior space, such as a castle model,
• the ability to shrink the model by half and enlarge it by double the scale,
• to cycle the model along the XYZ axes,
• You have the option to choose solid color blocks or blocks with textured material assets.
• the option to choose different block materials (which can be achieved by incorporating dependencies from different material projects, as long as the block names in each material library are ensured not to be repeated).
• There are two color panels (I originally planned to only keep one set), and I have not yet determined which colors to provide.
• You can even import terrain blocks generated by voxel terrain to perform internal editing. If you wish to manually edit an adventurer’s cave, this is a great option. It is important to note that the terrain blocks should not be too large, as this may cause the program to crash.

dependences(already imported into project, There is no need to manually import it into the project.):

• Block Library
• UI
• Cameras
• Touches

I would like to express my gratitude to the following friends whose shared code has been utilized in this project.
– Using @John Millard’s base code
– Using @UberGoober 's undo/redo code, voxel models and the new block library.
– Using @SugarRay 's objcTextView code.

The known bug is that the volume:resize(x, y, z) function exhibits a significant error when processing the X parameter. @John, it seems it’s up to you now, as if I recall correctly, you are the only one in the team who is an expert in these voxel module codes. Of course, when you have spare time available.

Some menu options may not be very intuitive in relation to their implemented functions. I will find time later to record some tutorial videos, or interested friends can start exploring on their own for now.

tut video:

• Create a model

Create a voxel model

• Save/load a model

Save and load a voxel model

• Half/double a model

Half/double a voxel model

• Split a model and edit its internal space

Split a voxel model and edit the internal space

note
You need to manually create a directory named “MyAmuseModels” under the Documents folder of Codea to back up your models. The backup is conducted automatically, and it occurs each time you exit the viewer normally, which enhances the security of your models. You can access it within the code using the asset key asset.documents.MyAmuseModels.

good news!
@sim helped us identify the cause of the performance issues in version 3.10 and provided a solution. After testing (on an iPad, Codea version 3.10.1), it has very perfectly resolved the issue, so our project no longer requires a specific version. All versions can now run smoothly! I hope everyone enjoys using it!

This video teaches you how to use TestFlight to downgrade the Codea version to 3.9.8 (443).

This video teaches you how to use TestFlight to downgrade the Codea version to 3.9.8 (443).

run on iphone(Codea version 3.9.8) video:

MyAmuseVoxel (version 3.9.8)run on iphone smoothly

The video was played at its original speed without any fast-forwarding.
Please temporarily ignore the UI buttons that may appear somewhat chaotic (as the UI adaptation for the iPhone has not yet been done).

• version log
  – V007[20240329]: itemPanel.lua modify the model loading path to asset.models.all
  – V008[20240329]: fix the performance issue with @sim’s help, modify _dep_Craft:UI cache spriteSize
  – V009[20240330]: backup models to asset.documents.MyAmuseModels when close viewer(exit)

Strictly speaking, this is a semi-finished product. The code is written rather casually (as it was developed in fits and starts during spare time), with a significant amount of redundant code. Many planned features are yet to be implemented, such as better color selection options and support for user interface layouts on screens of various sizes (currently, it only considers a 12.9-inch screen), as well as detailed online help (which I have not written at all; I originally intended to refine it thoroughly before sharing, but the recent version update has led to a sharp decline in performance.

I am very grateful for the assistance from @sim, and I have followed your instructions to disable viewer.warning. Other projects have returned to their original smoothness, but this particular project remains very sluggish. I suspect it might be related to my UI code, but pinpointing and resolving such an issue is a bit beyond my capabilities.

I have just tested several different beta versions and found that the project runs very smoothly on version 3.9.8 (443), but it becomes sluggish immediately upon updating to the next version, 3.10 (445).

I am not clear on what optimizations Codea has made internally that might have affected my UI code (perhaps the way I wrote the UI code has caused some conflict with the latest version of Codea), but identifying and solving this problem is clearly beyond my ability.

Moreover, I worry that with subsequent version updates, this fun project, into which I have invested a considerable amount of my leisure time, may become a pile of unexecutable junk. Therefore, although this project is still in an extremely incomplete stage of development, I have decided to release it. Perhaps other friends might be able to identify the cause of its sudden and severe performance degradation.

MyAmuseVoxel.zip (1.3 MB)

[UberGoober]

Looks fantastic! Won’t run for me. Says it can’t find “MyAmuseModels”.

[UberGoober]

When downloaded from WebRepo I get a different error:

Documents/MyAmuseVoxelV006/ItemPanel.lua:15: attempt to index a nil value (field ‘models’)
stack traceback:
Documents/MyAmuseVoxelV006/ItemPanel.lua:15: in field ‘init’
[string “-- Class.lua…”]:24: in global ‘ItemPanel’
Documents/MyAmuseVoxelV006/Player.lua:25: in field ‘init’
[string “-- Class.lua…”]:24: in global ‘Player’
Documents/MyAmuseVoxelV006/Main.lua:64: in function ‘setup’

[binaryblues]

@UberGoober Thank you for the report, I will update a new version with another model storage path.
If it is ok or not, pls tell me, thanks.

Btw. I realized that I made a mistake by including version information in the project name when submitting to WebRepo. It seems that the name in WebRepo can only continue to use V006.

[Steppers]

@binaryblues If you want me to I can update the name on the backend later to remove the version?

[binaryblues]

@Steppers Thank you for your assistance; otherwise, there would have been a discrepancy between the project name and the displayed version, I have also changed the project name in Codea.

@John Thank you for your prompt response. I read the code three times and then discovered the special part. Initially, my attention was focused on the inner loop body, however, in the end, I shifted my focus to the outermost statements, and I am looking forward to the update of the next version.

[Steppers]

No worries, I’ll let you know when it’s done

[Steppers]

@binaryblues Renamed https://codeawebrepo.co.uk/WebRepo/client/app.html?name=MyAmuseVoxel

It should also be renamed in the normal WebRepo project.

[John]

Look great @binaryblues

Can you remind me what the issue is for volume:resize(x, y, z)?

[John]

Doh! There is a pretty obvious error in my C++ code:

See if you can spot it

EDIT: Submitted the change so it’ll be fixed in the next beta and release

[binaryblues]

@Steppers Thank you for your assistance; otherwise, there would have been a discrepancy between the project name and the displayed version. I have also changed the project name in Codea.

@John Thank you for your prompt response. I read the code three times and then discovered the special part. Initially, my attention was focused on the inner loop body, however, in the end, I shifted my focus to the outermost statements, and I am looking forward to the update of the next version.

[UberGoober]

I got it loading. It looks cool but The UI is pretty borked on my iPhone:

Also it’s very slow to move around. You can look at mine for reference—it swivels around very fast. You seem to have done some great stuff in terms of adding more functionality than mine has, but the slowness is an issue.

I was curious how you’d solved the problems I ran into with placing voxels on the back, left, and top walls, and I was amused to see that you did it by just removing those walls! I’m assuming you did that because you ran into the same errors I did and couldn’t find a way to fix them either?

If so, while I feel your pain, I don’t think removing those walls is a viable solution. Maybe I’m wrong—I haven’t tried to build anything yet with this because the UI is squonched—but with other voxel editors all six walls are interactive and I think that case has to be cracked somehow.

Would you want to collaborate in some way on this? I don’t know what I can really offer other than consultation but since we’ve both put tons of time into making improved voxel editors I think we might be able to productively confer.

[binaryblues]

@UberGoober Thank you for your feedback. Thankfully, it is finally running! Currently, the project has only been tested for UI layout parameters on a 12.9-inch iPad screen, and the UI layout parameters for the iPhone are still blank. You can temporarily try adjusting the relevant parameters of the MenuLayoutParams tab. If I have time later, I will add UI parameters suitable for different sizes of device screens.

Regarding the issue of slow speed, I mentioned in the version requirements that you need to downgrade to version 4.9.8 (433). Just now, I tested it on the iPhone and found that the official version on the App Store has also been updated to 4.10, which indeed is very slow. It seems I need to update the instructions—-all installations of Codea obtained from sources need to be downgraded to version 4.9.8 (433); otherwise, it will severely affect the user experience. I just tested the performance in both the official version 3.10 and the beta version 3.9.8, and found that 3.10 is indeed slow, while 3.9.8 is very smooth. Therefore, I suggest you downgrade the version and give it another try.

I am glad to see that you are interested in participating in this project. As I mentioned in the project description, there are still many unfinished parts, such as：

• UI adaptation for different screen sizes,
• selection of color sets in the color panel (which seems to require a more keen artistic intuition, which I lack),
• built-in usage help, detailed usage tutorials (some operations are not intuitive for beginners),
• better save implementation,
• better support for voxel terrain (currently requires manual cutting from the voxel terrain generation program),
• and so on.

I suggest you could start by adjusting the iPhone UI layout, which can also lay a good operational foundation for your subsequent actions.

[sim]

I’m going to run your project through the profiler and see if we can get to the root of the performance issue in 3.10

[sim]

Good news @binaryblues, I’ve found the performance issue with 3.10 and there’s an easy fix you can implement in your project:

In the tab _dep_Craft:UI, change the function ui.image:setImage(img) to cache the size:

function ui.image:setImage(img)
    self.img = img
    if img ~= nil then
        local w,h = spriteSize(self.img)
        self.w = w
        self.h = h
    end
end

THEN, in ui.image:draw(), there are two places spriteSize is called. Please replace them with:

local w, h = self.w, self.h

AND

local sx, sy = self.w, self.h

[sim]

Why is this slow?

In 3.10 we formalised the reading of asset keys so that they interact with other file operations in the system. When you attempt to read an asset in Codea 3.10 (via readImage, spriteSize, sprite, shader… anything), Codea now does the following:

1. Resolves security scoping in case the asset lives outside of Codea’s sandbox (i.e., you imported an external folder containing the asset)
2. Coordinates the read with the operating system to ensure that anything else accessing the file gets a chance to save it

The slowdown happens on (2). When spriteSize is used, Codea will read the file from disk every single time to calculate the size. It doesn’t cache the size, and does a full coordinated read of the asset key

For the sprite command, Codea caches the texture and so subsequent calls to sprite after the first one will be quicker (as this command is expected to be used in the draw loop)

We could probably look at optimising spriteSize to use the size of an existing cached sprite if one exists. But for now, you can follow my instructions above to restore performance to your project

[binaryblues]

@sim I am very grateful for your explanation and the provided solution; you have once again saved this project! I have tested version 3.10.1 (456) on the iPad, and apart from a slight increase in startup time (about 3 to 5 seconds), the modified code has perfectly restored the original smoothness! Thank you once again!!!

[sim]

In the next beta we will update spriteSize to use cached values where possible. I tested and it fixes the performance of the original version of your project without changing the code

[binaryblues]

@sim It is great to hear this news, and I look forward to the early arrival of the next version update!

[UberGoober]

@sim

2. Coordinates the read with the operating system to ensure that anything else accessing the file gets a chance to save it

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

It just makes me wonder what the gain is on the user’s side, seeing as the cost is potentially so high, on one hand, and on the other hand, I don’t think I’ve ever found myself confronting an issue with “coordination of a read with the operating system”.

Is this a fix for something that people who don’t use AirCode will never encounter?