R0J0hound

Testing the indexing right now, and it seems to be working. We could potentially use an unlimited number of points in the point cloud. It doesn't really matter... it would take longer to build the index though, but once the index is built, we never really touch the points.

Level 0 index. the average color and coverage of the shape. This is only used if the entire object fit in one "pixel" area.

level 1 index. 2x2x2 array used when object fits in a 2x2 pixel area, and so on.....

level 2 index. 4x4x4 array

level 3 index. 8x8x8 array

level 4 index. 16x16x16 array.

level 5 index. 32x32x32 array. This is the maximum I've tested so far, and looks great on a 32x32 tilemap.

you could go as high as your native screen resolution. 1920x1920x1920 for example. Ideally we could crop the away unused whitespace in the array so there's less area to search.

Building the indexes is the easy part. Preferably we would have these prebuilt in a custom file, as the point cloud data is irrelevant once the indexes are built.

I still have to figure out how to rotate the index. I'm an artist not a coder, so i can easily visualize what I'm trying to accomplish, but hard to do the actual syntax for it.

Will share a capx once I'm done with the testing of building indexes.

Although so far it seems performance is not based on how many points in the cloud (we could use millions) but rather the efficiency of the search algorithm (how fast per pixel we can get the rgb value from the index) and the actual render resolution.

50x50 would be pretty fast, but 1200x1200 would be slower, unless we can optimize the search heavily.

If we store RGBA in each cell we can get a bit more detail and antialiasing effect like this. We could store more information in this index, like surface direction, normal direction etc etc, but RGBA should do for now.

Pic 1. If the ball fills only one tile, we can get the rgba value for the ball at index level 0. that's the average color and coverage of the entire ball.

Pic 2. If the ball fills 2x2 tiles. we would get a semitransparent red shade from from each cell in index level 1.

Pic 3. If the ball fills 8x8 tiles, we get the the rgba value from each cell in, index level 3.

The only problem so far, is how we translate or rotate the object. Ideally we would rotate/translate a bounding box (or the index), instead of shifting all the points and values in the array creating a new index every tick.

Have an idea that possibly could make it a lot faster. It's a pretty experimental approach to how we generally think of 3D. It would involve restructuring the point data, and have it indexed. I got the idea by looking at the way you get the point positions and the rgb value for those positions. Basically it would work like this...

It's pretty much creating a search algorithm, only getting relevant data from the point cloud, limited to number number of "pixels" in the tilemap.

Every cell of the tilemap just searches for a the color value it want's to show, and maybe we could get that directly from the point cloud if it was indexed. Translations and rotations would be done at Bounding box level for the object, so we don't need to reposition points individually.

For a quick indexing test. You mentioned the data i pretty normalzed already, so we create 50 steps between -1 and 1. If we take the point cloud data, populate a 50x50x50 array with the average color of every point in each "cell". so if there is any point with the value 0,0,0 we would place the rgb value of that point in the dead center of the array. if a cell has no value, it means transparent, if has a value, it would render to the tilemap.

If we can have some kind of bounding box representing the array data that we could rotate & transform A simple search from the each individual cell of the tile map looking at that bounding box, could get the indexed rgb rgb value of the cell it's looking at. For example. tilemap 25,25 is has the array cell # 26,25,12 (we can disregard all cells behind it as it is opaque)in it's view we would know what color to display for that individual pixel. If a tile map pixel is looking has multiple cells in it's view, we could get the average color of these, that way we could have something similar to anti-aliasing as well.

LOL. hopefully you can understand what I'm rambling about. I'm going to do some tests indexing the point cloud data, so we can minimize the data we need to get. Theoretically you could have massive amounts of points, if you can get them quick enough from files on disk with an index, you probably wouldn't even need to load them in to memory.

As long as each pixel know's what he's looking at, he could jump directly to the index point and get the color information from the correct "cell". the tile map cell is basically jumping straight in to "Column, 6, row 9, z 8, and getting the correct rgb value.

I was also thinking maybe it's possible to store x, y, z in one value using rgb() format. If so.... A one dimensional array could hold all the position values... Maybe you would lose some accuracy with using rgb value, but maybe not noticeable with tile map rendering. Haha ...here's a wacky idea. Theoretically you could pretty much control point translation using color. 0,0,0 (black) would be top left corner deep in z, while 1,1,1 would be bottom right near in z.

If we normalize the hidden point cloud positions based on the window width and height, we could also store these points in a 2d array the same size as the tile map, and maybe use that as an intermediate before rendering with the tile map.

Nice. I played around with it a little bit and managed to get a constant 60 fps but that was only when rotatating in one axis. I'm going to continue my tests tomorrow to see if I can push it even further.

Using the tile map is very easy on draw calls but heavy on cpu, using sprites is heavier on draw calls but a lighter on the cpu. I'm going to see if I can figure out a way to make it even less cpu intensive. I have some ideas I'm going to try out tomorrow.

I'll get back with results once I've tried it.

cjbruce Thanks for the replies. I'm considering recreating my game using Q3D instead, as I'm having some trouble simulating physics and arrows in a 2D isometric view, and memory budget is getting limited by the number of sprites and animation frames I want to use.

you can test a demo here http://www.tunepunk.com/arrowheads It's also multiplayer using photon cloud.

(preferably on a tablet or mobile phone as it's optimized for touch at the moment) I want to lay out the map using a top down view, and then have a camera follow the player in an isometric perspective. I think could save a lot of memory and have more varied maps & terrain by using 3D shapes instead. I have all the assets in low poly as well.

I tried the mobile demo from this page so performance should be fine... I guess i have to give it another go.

It's more of a point cloud renderer than a voxel one. I'm pretty sure something more efficient is done with voxel renderer's than drawing everything.

Loops in the event sheet are probably the biggest culprit of why it's slow. I've compared equivelent loops in just JavaScript and they're over 20x faster. I guess in general the slowdown is events are interpreted and there is some overhead involved with it.

R0J0hound, I just had a few ideas on how to speed it up. Since the loops seem to be the problem, and not the actual rendering I was thinking of different ways of how to optimize it.

Event based for each loops are not very good. There's the internal higher level ones that's a lot faster, (like when you pick something by a variable/boolean/family there's an internal for each) so here's my proposal approach.

On start of layout. Create Hidden sprites on a hidden layer and set XY and (and maybe a variable for Z). You could even pin them to a dummy object then Rotate dummy object, or rotate the entire layer, to prevent any picking which also a bit of a performance hog. I'm imagining these sprites would represent a top view in this hidden layer, rotating the dummy object would be a rotation along X axis. (horizontal in a front view). Then have the values from these hidden sprites drive the tile map rendering? Basically no loops would be needed to calculate new point cloud positions when rotating the object. Do you think something like that would work?

If that works Maybe more if these tricks can be used to limit the amount of loops, and increasing the performance without using js.

Impressive R0J0hound u basically made both a mesh and voxel renderer in 50 events.

Took a look at your example and tried to identify what was so heavy on the cpu. Draw calls seemed very small, so it must be updating the rotation every tick. None the less it's a very cool example of what can be done with a bit of brute force and Vaseline.

My main goal with the experiment was just to see if it worked and clearly you have proven that it does. Very nice example indeed. I really liked the use of Tile map object to draw the pixels. Clever.

I kind of agree with OP. Even though Tom mentioned not considering it, I'm sure they will work out a solid plan.

Considering they moved C3 online, the last thing you want is a ton of free users using up bandwidth and data for extended periods of time. Each free user is going to be a cost for scirra as long as they can use C3 online, no matter how much they limit functionality.

If you only limit exports. A person can use C3 for years producing a bunch complete games, then just paying when they are done = Really bad business decision. Especially since they mentioned that you are able to earn money on your games even after licence expired.

If you limit events, Families, Layers and other stuff like C2, I think. it's still going to be costly in the long run as long as people access the tool online.

For me a free version should be like a tryout, get a hang of it, tinker with it, play around. If you like it... then pay for it. 30 day trial seems like a sensible option though But I'm sure they thought about it. From a purely business perspective, the last thing you want is people to abuse the Free version, and stealing bandwidth, stability, server performance, etc from paying customers, using it for months or years without paying.

R0J0hound Yeah voxel data would do the trick.

Just theorizing here of a possible way, maybe you have some input.

But wonder if there's any raw format or a way to convert it to JSON or something, easily readable by construct. Basically what you would need is only XYZ position for each voxel (point), and maybe color information for each point. (Rgb)

For each voxel, you then draw or place a 1x1 pixel sprite on screen.

I got the idea from here, which I'm sort of trying to back-engineer now.

Just to start simple. Imagine you have a screen resolution of 50x50 or pixels, for each pixel you want to cast a ray forward. If they ray hit something in 3D space (a point in the point cloud or the average color of a group of points) you render that pixel, in the correct color.

I'm just curious to try out the voxel/point cloud approach also, to see if it would render faster, since you don't have to draw triangles. Just getting the RGBA info from a point in 3D.

That's pretty awesome R0J0hound ...u got a lot further than me on that. It's quite amazing it worked that well.

I was just going to try a new approach as well trying out rendering point cloud data just for fun, but currently stuck since I didn't find any good (free) software to convert some model to point cloud data yet, as in this case I thing it would be faster than drawing polygon data. Not a very dense point cloud but a bit bloated points to fill the gaps between them.

You can use Global Variables to save coins between layouts.

You can use local storage to save the amount of coins you collected.

I'm using local storage to save score.

https://www.scirra.com/manual/188/local-storage