#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

# Global MaruFight

edited April 16 Posts: 1,795

I’ve attempted to draw MaruFight onto @dave1707’s globe/icosphere.

I feel good that I got it working in some way, but it looks pretty gooby, I think it needs a Mercator projection or something like that and I don’t think I can figure it out.

It would be pretty cool if it worked though right? I would greatly appreciate if anyone could tell me how to fix it. You can see the flaws clearly in the video.

Tagged:

• Posts: 1,795

Posts: 762

Reminds me of agar.io

In terms of projection I assume you mean the stretching at the poles? Technically a 2D wrapping space like that would map directly to a torus rather than a sphere.

The only thing I can think of that would map cleanly would be some kind of cube-map: https://en.wikipedia.org/wiki/Cube_mapping

Not sure how that would look though?

• Posts: 1,795
@John I agree, a cube map seems like it might be easiest in terms of visuals, but coding-wise it’s difficult for me to get my head around how I’d do the math for when little circle dudes (marus, I guess) move off the side of one part of the cube map.

It seems like it has to be possible to reverse the math on a Mercator projection, which would eliminate the movement problem, but I can’t get my brain around that either.
• Mod
edited April 19 Posts: 9,977

@UberGoober You’re not going to map a rectangle onto a sphere without some sort of distortion at the poles. Why you’re getting that black star at the top and bottom I don’t know. When I wrote the sphere code, instead of there being one pole at the top and bottom of the rectangle to map to it, I created 6 poles evenly spaced across the top and bottom to better map it and reduce the pole distortion. When I use a map of the Earth, there aren’t any dark star shapes at the top or bottom poles of the globe. See the Earth zip code below.

One thing that surprised me was looking at the Pacific Ocean. You can rotate the Earth so the ocean covers the whole view with some land just around the edges.

You can also zoom into the Earth and see the continents from inside.

• Posts: 1,795
@dave1707 okay I’m trying to think this through, because I think your grid map in your original project gives good clues, so let me sketch out how I think it would work…

So let’s say the bottom of a square at the equator is 18 pixels wide, and the bottom of a topmost square (whose top converges to a single point at the pole) is 4 pixels wide, that means for a maru 7 pixels wide to look the same size at the top as it does at the equator would require it to scale by 18/4 or 4.5.

So for a maru to travel from the equator to the top of the globe and look like it stayed the same size, I would need to somehow enlarge the image at basically every row of pixels using an algorithm that provided a smooth scaling from 18 to 4… and at the same time reduce the amount of space marus have to move around in as they near the top… and there’s where my brain breaks.
• Posts: 1,795
…or is there maybe some simpler way to get the marus moving around on the globe? If they were actual 3D objects it wouldn’t require any of this, but then I couldn’t use almost any of the original code… not sure which is harder… seems like the Mercator projection issue should be solvable…
• Mod
Posts: 9,977

@UberGoober Would this help any.

• Mod
Posts: 9,977

@UberGoober I figured that problem out at some point and wrote code that would solve the problem. The only problem is, I don’t remember what I wrote it for and I probably deleted it. The code was what kind of a circle/ellipse would I have to draw on the rectangle so when it was projected on the sphere it would still look like a circle at the equator and as it got closer to the pole.

• Posts: 1,795
@dave1707 that would certainly help, but the projection is only half the problem, the other half is figuring out how to make the marus move and detect each other as they near the poles.

So if we go the reverse-Mercator route, there will need to be both complicated math and complicated environment-detecting adjustments.

It’s beginning to look like a cube map might be best course after all, because while the math is still complicated, I can at least conceptually get my head around it.
• Mod
Posts: 9,977

@UberGoober Instead of a cube, you need a larger sided figure. You still have the flat surfaces for movement and collisions, but as you increase the number of sides, it approaches a sphere.

• edited April 20 Posts: 1,795
@dave1707 that would indeed be ideal but I don’t think I could ever do the math.

When it’s just a simple flat image, for example, I have to calculate what happens when a maru goes off the top, for instance, and when it goes across a corner, and that’s all very simple up-and-down math.

But with a cube map I’m going to have to figure out which edge leads to which edge, and it’s going to involve doing some rotations and right angles and all that—it’s going to be complicated but at least it’s all right angles or multiples of them, and I think it’s just right at the edge of my math ability.

But with any more than 6 sides all the calculation gets harder by orders of degrees, literally, and I just can’t do it. If you can though I’d love the help!
• Mod
Posts: 9,977

@UberGoober It’s not something I want to get into. I haven’t played with the flat version, so I’m not sure about the purpose of the round version other than you wanting to do it. I do a lot of things like that too, where it’s more about the challenge of doing it than what the final results give.

• Posts: 1,795
@dave1707 ultimately I think it would be cool to get little critters running around and fighting each other on the surface of @John’s planet generator. This seems like a baby step towards that. And that uses a cube map anyway so maybe that’s another good reason to do that way
• Mod
Posts: 1,350

My guess is, to look right on a sphere, your best bet is to do the sphere math. I' d have to look it up and read to be sure, but the guys would have constant angular change over time. We're i to do it, I'd start with one dot wandering the sphere, I think. I'll try to get interested enough to do it, but I'm not optimistic.

Posts: 762

@UberGoober Have you thought about drawing the marus as 3D objects on the surface of the sphere? It makes some of the maths a bit more complicated (tangents instead of up/down/left/right and distances become the shortest distance along the sphere's surface - http://www.miguelcasillas.com/?p=107) but technically should work roughly the same.

• edited April 22 Posts: 1,795
@John I thought about that and there are two arguments against it: one, I’d have to completely rewrite the maru code, and part of the fun here, for me, is going fast by using existing code; and two, Since ultimately I would like to get the marus running around on the surface of your planet generator, and your planet generator uses a cube map for terrain generation, if someone ever wanted to make the marus react to specific terrain features, like height for instance, it would make the most sense for them to also be plotting their motions on that cube map.

… unless I’m misunderstanding what you mean…
• Posts: 1,795

@John can you provide any information on the properties of a `cubeTexture`? This looks like an undocumented feature that is used in your planet generator. I think I will need to know this to draw marus to a planet’s surface.

• edited April 23 Posts: 1,795

@John—this is a demo of what a MaruPlanet would look like—it runs very slowly because, to change the planet map, on line 184 in Main I have to rebuild the colorMap cubetexture every frame.

Is there any way to write directly to the images inside a cubetexture so the simulation can run at a better rate?

• Posts: 1,795

• edited April 24 Posts: 1,795

Forgot to add actual project: here it is.

• edited April 24 Posts: 2,689
@UberGoober - what you could possibly do is have two spheres one inside the other with the outer transparent, then only update the Maru graphics file. Or am I missing the point?
• Mod
Posts: 9,977

@UberGoober You’re getting closer. Loaded your zip file and ran it. Noticed that some of the Maru would disappear as they left a cube edge. Not sure which edge they were reappearing on but you don’t have the code right when leaving an edge and appearing on the adjoining edge.

• Posts: 1,795

It runs better on my iPad with the planet’s number of facets turned down.

• Posts: 1,795

@dave1707 I know, that’s why I call it a demo. I don’t have that math worked out at all.

Posts: 762

@UberGoober looking at your changes, the rendering is slow because it creates a new cubemap every time it updates the marus. Mapping them onto a cube map by drawing them on each face will cause some distortion around the cube edges as well as clipping when they don't line up.

There is a special undocumented thing that could help you out: `renderTarget`. You can create a render target by giving it an existing `craft.texture` or `craft.cubeTexture`. You can then use `camera:draw(target, cubeFace)` to make a craft camera draw directly to a cube texture face. This would be much faster than creating a new cube texture from scratch every time but is a bit more tricky

The above might help but I think ultimately this is a case of trying to force a square peg into a round hole. You can't really map a square texture map onto a sphere without some extra work to make your 2D entities line up with the edges or placing them in a 3D space

• Posts: 1,795

@John thank you for the secret sauce! That’s just what I was looking for, I think!

The deciding factor keeping the creatures in 2D, I think, is that if I ever want to make the marus aware of their environment, the simplest way to do that is to make them aware of the cube map, and if everything is going to go back to the cube map eventually, I might as well just draw to it too, no?

• Posts: 1,795

@John could you possibly provide an example of rendertarget in action? It does seem tricky.

• edited April 27 Posts: 1,795

Attached is the project that attempts to use renderTarget and causes this amusing fail.

Posts: 762

@UberGoober I a see. Well all it does it make a camera draw to a side of the cube texture. I'll think about how it would need to work

• edited April 27 Posts: 1,795

@John, OK, I think I understand: it is drawing the current image that the camera sees to the target that is specified. So it doesn’t have to be turned on and off the way that drawing contexts are.

So it seems like the way this would have to work is to somehow position the camera so that it only sees the part of the Maru plane that corresponds to side one, and then set the render target to side one, and then position the camera so that it only sees side two, and set the render target to side two, and so forth, for each of the six sides, and then return the camera to its normal position.

Alternately, I guess, and what might be simpler, is to draw each square of the Maru fight with the right positioning and dimensions that it fills the camera in the camera’s existing position, so that the camera itself doesn’t have to be moved at all, and set the render target appropriately between drawing each Maru square.

I think the trick in both cases is positioning the Maru plane so that it precisely fills the camera’s field of view. Any tips on doing that?

• Posts: 1,795

Well, I tried the above and it kind of worked but not enough that it’s usable.

Why am I getting this weird effect where the texture is only visible from some angles?

Posts: 762

This would be due to mipmapping I think. You could try calling generateMipmaps() on the cube texture after updating it?

• Posts: 1,795

@John thanks for the tip!

so close!

Thoughts?

• edited April 30 Posts: 1,795
@John I reduced the planet radius to 1, which made it a cube, which gives us, I think, interesting information.

It looks like for some reason `camera:draw` is doing two weird things:

- it only renders the image at exactly 1/4 the size of a cube face
- it puts a thick black border on the bottom and right sides of the image

(Project attached)
• Posts: 2,689

@UberGoober - after playing a little, then pressing Generate, it crashed Codea.

• Posts: 1,795
@Bri_G yeah right now apparently the renderer can only handle really small images. If you try to increase the sizes of things it crashes pretty fast.
• Posts: 1,795

@John does one of the example projects use `renderTarget` so I can see an example of it working correctly?

Posts: 762
I don’t have any examples on hand since render target is mostly used internally (for things like bloom). All it does it draw to a craft texture using a scene camera, which it looks like you got working?
• Posts: 1,795
@John it doesn’t apparently draw to the whole texture, just the upper left corner of it. The texture covers the whole cube face but renderTarget appears to only cover a corner.
Posts: 762

I assume you're drawing to an intermediate image, which you then place in a scene to use with the renderTexture, it might need to be moved and scaled to take up the entire cube face (instead of a quarter). The scene's camera might also need to be set to orthographic so that perspective projection isn't making things look weird

• Posts: 1,795
@John no matter what size I make it, it only takes up 1/4 of a cube side on the globe.

I have 6 plane models set up in front of the camera, all the same size and position to fill its field of view, and each one has a material.map corresponding to one side of the cube.

Every draw cycle I toggle their “active” setting on and off one by one and I use “camera:draw” to render the camera’s field of view to the “gen.map” cubetexture.