if you can draw a diagram of how the different values interact, like explaining the function of each of the sphere equations and what events use which, and why, I might be able to help. I've made 3d spheres and such in construct before. quazi's done much more 3d stuff. It all makes sense when you're the one doing it, but , for me at least, without having freshly been working on sphere math, deciphering this over a large cap would be tedious, especially not knowing which part is an error.
An explanation of the math you're using, from which frame of reference would be helpful. for instance, is there a fake camera running through private variables and events, if so, how does it interact with the magiccam. why -270. If you're using sphere math, a basic diagram showing construct properties and variables as they correspond to the terms in the equations, especially the ones dealing with normals or surface angles, since I believe that's where the problem is. Without some basic information, it would be a bit of a project just to figure out what's going on.
I've made a few changes, mainly I've removed a couple of scrap values and events that had no real purpose or were for thing not really pertaining to this. Also the reliance on color replace was taken out (Part of a lighting experiment)
Anyway, the math I'm using mainly came from Wikipedia's perspective projection page ( I use the non-matrix code, but stop when I have 3 values). Also bits of codes from the 3d wolfinstein demo and my modification of it.
1.Is their a fake camera?
Yes. Everything is faked...except for camera rolling. This is why the formula is filled with Cos(0) and Sin(0), since these are where the camera roll angles would have normally gone (Kept in in case I needed to make comparisons to the original formula)
2.How does it interact with Magicam?
I actually don't have a complete clue. But it has to do with camera rolling. I've checked head to toe for references to Magicam in the events, but can't find any. But when I remove the inlevel instance, Roll controls stop working.
3. Why -270?
The design I was going for had the 2D map be a overhead map. The formula I had created however made the map become frontside view. I compensated for this by tilting the camera 270 degrees. The pitch of the block is set to camera pitch-270 to counter act the camera's rotation and make level design easier.
4. The Values.
"World" Block positioning is similar to the wolfinstein examples. Position in 2d space determines 3d X and Z. The map pieces have a "3DY" value that determine just that...the block's Y position in 3D space. The camera also uses this.
The size of the blocks are also determined in a similar fashion, with 2d Width and Height determining 3d width and depth. And a separate "Height" variable for actual 3D height.
The "World" Yaw of a block is determined by it's 2D representative's rotation on the map, and its "World" pitch by a private variable held. How to actually get said world pitch to work is what I'm inquiring about. There two blocks with a non-zero pitch, they are the two lone striped (Cyan) blocks.
The test global variable is simply a runtime adjustable variable that currently serves no purpose.