It looks like you're new here. If you want to get involved, click one of these buttons!
@John @Simeon i would like to have two scenes that i can switch between, each one having an independent OrbitViewer. I was able to make this partially work but unfortunately if i move the camera in the first scene it is also moved in the second scene. Is it possible to have two cameras/orbitViewers with independent locations or do i have to memorise the camera position for each scene and refined the starting position of the single camera at each scene switch?
Comments
@piinthesky Is this close to what you’re looking for.
@dave1707 that is what essentially i am doing currently. i don’t see why you need your touches function as the orbitviewer handles the touches itself. if i comment out your touches function, then only the scene2 viewer reacts to touches.
@piinthesky That’s why I added my own touched function. The 2 scenes can be seperated whereas using the OrbitViewer touched function doesn’t seperate them. The OrbitViewer touched function uses the last scene it was added to.
@dave1707 yes that’s the issue. The touch handler in the orbitviewer is not unique to each scene-not sure how to fix that in an elegant way.
@piinthesky - have you tried having two cameras defined which stay at the same relative offset to each other. I thought about that for use in a 3D application. I’m sure Ignatz did that with his spitfire project with a camera view from inside the cockpit and one to the rear. In fact it’s one camera with an offset when you need to switch views.
@piinthesky Not sure what you’re exactly after, here’s another example of 2 different scenes. I altered code from my starter game 22 code to create this. Tap screen to start, tilt screen to turn and slide the parameter slider to change screen. A lot of different scenes could be created, I would do it different though.
@dave1707 @Bri_G i was hoping to ‘elegantly’ use the orbitviewer and the touches handler to treat independently the camera positioning, panning and zooming etc. for the multiple scene case, rather than having to reinvent the wheel.
@John, i think dave1707’s first example above ‘fails’ because the touch is captured by scene1 and never gets to scene2. How does one implement shared touches with touchhandler? there is some code for shared touches but it does not seem to be available as an option?
@dave1707 this seems to work.....
@piinthesky That sure does work a lot better. Thanks for sharing. I’ll have to keep a copy of that for reference. I wonder how many other things there are that we don’t know about.
@piinthesky I tried creating more scenes, but they don’t seem to work. Change the for loop value so you create different number of scenes. If the number of scenes are 1,2, or 3 they all seem to work OK. If you create 4 or 5 scenes, then only the first and last scenes work OK. Don’t know if it’s my code or the touch handler that not working right.
Hi guys, the whole Camera library and Touches library were never really meant to be used for multiple scenes. It's probably better to just copy those projects into your project and then modify them as you see fit to fix any issues like this. Calling things manually like @dave1707 is doing is probably the best option.
@dave1707, another try! this might be the correct way to do it (nice to find a way reuse @John ‘s code)
note that the touch.handler is not necessary if there is an explicit touch function call in the main code. in fact in that case the touch.handler call in the orbitviewer.init can also be removed.
@piinthesky That seems to work, but you’re constantly creating the ov table in the touched function as you’re moving your finger.
@dave1707 third time lucky!?
@piinthesky Good job, that one looks OK. Since the touched function is in this code, the Touches dependency doesn’t have to be checked in Cameras. But it still needs to be checked for the other projects that use OrbitViewer.
@dave1707 - hi, just revisited some old code you provided when I was having trouble with viewers. It was in the a thread about 3D model viewing, and was the final code sample in the thread. You set up a cube of spheres with a line of spheres internally and a further sphere outside the cube. The code allowed you to rotate the camera around the models by changing the viewer x,y and z values.
I thought I'd revisit it after reading this thread and ran into a problem - probably my misinterpretation of the code or the conventions used in the 3D Codea universe. The problem is - when I change values in the X axis the models rotate on the Y axis and vice versa. The Z axis just acts like the expected zoom.
I have heard of some conventions exchanging the Y axis with the Z axis, is that the case here?
@Bri_G Can you give the exact name of the discussion. I’m not finding it and the code doesn’t sound familiar.
@Bri_G I found it, I just didn’t go far enough back. My understanding of the axis is the X axis goes left and right. The Y axis is up and down and the Z axis is forward and backward. When I adjust the sliders, the image rotated on the correct axis.
@Bri_G Here’s another demo. The red line is the x axis. Green is the y axis and blue is the z axis.
@dave1707 - thanks for that, I was misinterpreting the way the system works. I thought that changing the x value would affect the y an z axes, not the rotation around the x axis. But there is something wrong with your demo. Rotate around any axis and the other two axes should both move,. The z adjustment is not in the update. I put it in but it still isn’t working properly.
@Bri_G I changed the range of the sliders from -30,30 to -120,120 and the camera position closer to the center. That should show the rotation more. As for the Z axis, that’s just zooming in and out and can be done using the 2 finger squeeze and spread.
@Bri_G I modified the above code to allow zooming in/out using the z slider. I also corrected an error I had with the red x axis. It was originally 2000,1,0 and it should have been 2000,1,1. I don’t think the OrbitViewer rotates around the z axis like the x and y does, but just zooms in or out.
@dave1707 - modified your code a little, what you say is correct the v.rx and v.ry do rotate around the x an y axes respectively in degrees. The v.rz is not accessible as I think @John has used it as you describe - a zoom function.
I think I can use the viewer as is to achieve what I need. Hopefully I’ll post something soon to describe what I find. Thanks for your help.