Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pjcast]

We disscussed this a bit in IRC. However, good to get some design stuff down on .. err. paper (or forum ).

I think that there should be a base class Camera. This camera can be controlled easily by script.

Then derived from that would be:
ThirdPersonCamaer - RPG stlle, slight above, follows object, does not rotate
FollwMeCamera - directly behind and raised up, can rotate along with object it is tracking
FirstPersonCamera  - FPS style camera
SecurityCamera - The camera tracks an object, but has a fixed point it is anchored to, ie like a security camera.

More? What do you think.. Of course, there would need to be some behavior tweaks (like following distance, speed, etc) that could be created in script for each specific camera.

Anyway, you create the desired camera, then set it to track an object (Actor*).

[mysterycoder]

Maybe also a Movie-Style camera, one that can move along a spline, for an epic movie-like effect    I also think we need to have widescreen support, and widescreen on moniters that are not widescreen(4:3 etc)

[pjcast]

Sure, other types of camera systems would be possible. A spine based (preconfigured path) one would be cool.

I;m not sure what is involved in supporting widescreen. The resoultion can be anything, but if you are reffering to changin the camera's FOV, that would be possible.

[mysterycoder]

Sweet, I have done some simple things that calculate what the resolution of a viewport should be if its apsect ratio is something like 16:9, or 16:10, on a 4:3 moniter. I think they are a bit inaccurate though  :oops:

[pjcast]

I think getting a sweet camera system going should be the big push in Version 0.2

Then, the next big push would have to be getting physics... As, with Sound, Meshes, cameras, and physics.. we could easily create a nice ShowCase application (demo) download.. 1) Help attract developers/artists to WGE.. 2) Coolness factor 3) 4) $$$ :lol:

But, seriously, WGE needs some surge in interest if it is to ever become popular... Even though we are in the infant stages, it never hurts to have people backing you

After that, it will be just more binding/tweaking/small feature additions/optimising/etc etc... Then we can each at least have a solid base to start working on our own game ideas.

[mysterycoder]

Yup, people are definatley good to have  :wink:, a bada$$ artist would really help attract intrest. Another thing that attracts is good documentation. Maybe we could start some wiki tutorials, and maybe some doxygen docs.

[pjcast]

I've spent some time earlier today doxygen commenting the Audio/Video stuff earlier today now that you mention it

I plan on actually writting some good (in PDF format) docs eventually (possibly even a small book - self published maybe). But yeah, some more wiki pages would also be good

[pjcast]

Woot! I commited the first basic camera class to svn. The world2.nut series of scripts shows it off. Basically, a free looking/moving camera.

Next camera will be a tracking one, tha follows the node given to it.

[mysterycoder]

Jeez, you're fast   , nice job on the camera   , but I think you have the forward and backward movement controls backwards, also I think the nearClippingPlane is a little to far, you can see the terrain popping out from under you.

[pjcast]

Hmm, the translate? I don't see how it is reversed? As I just send XZ to the snenode tranlsate.. Or, are you refferring to the Robot's movements? As, he has been kinof off since he was added

About the clip planes, sounds like additional methods need to be binded.. I am workingon adding some derived classes atm though.

[pjcast]

Ok, I just added the derived class FirstPersonCamera (Boy, that wasn't too easy either - if you look, you'll notice I needed typedef's (I searched the squirrel forum for that little bot of help)).

It doesn't do anything different yet, but it will. Basically, this will take a scenenode to follow, and a forward look vector, and just look there. Maybe some smoothing factors if needed later.

Of course, you are right, the base class needs some methods for the clip planes, but there are other useful thigns too (I wish it was easy to bind an Ogre::Camera ).

[mysterycoder]

Maybe it is what you intended, but if you run world2.nut, and press the up arrow, the camera moves back, and if you press the down arrow, the camera moves forward.

[pjcast]

Oh, I hadn't noticed before. But, this is because I set the parent scene node o that of the Robot (::human). So, by pressing the arrows and moving the robot, the camera moves with it. And, I think the camera is facing an odd direction (at least, compared to some other meshes).

In any case, not a bug, just an odd motion You can change the Parent node to the root node and it will not move funny. Well, it will not move at all in that instance

[pjcast]

Ok, I think instead of having multiple classes for the camera, after I have realised that most of the code will be the same.. And it just adds more bindings, and in perhaps more overhead then needed... Plus, it is nasty binding the inheirited base class members to SqPlus.

So, I think a general enum of Wge::Camera::Type { FreeLook, Track, etc };

And, a WGE::Camera::setStyle( Type )

Sound OK? I am also looking at the OgreSteer demo which has a decent (pretty interesting) camera system, and there a re some nice wiki camera articles I'm checking out.

[pjcast]

For the mean time, the world2.nut has messy camera movement.. This is a known thing