Camera Changes

#1 Are you refering to a camera that is constantly centered behind the player? If so that's the default 3rd person camera.

There is also a RTS type tutorial that gives you more of an RTS style camera. The camera in T3D has a lot more built in functionality than the two previous engines.

#2 Well, I'm referring to a 3rd person camera for an adventure type game, not an RTS. Basically, I don't want any strafing movement/code - I'd rather have the character turn then run, but have the camear intelligently follow.

I thought by now this sort of camera would be a standard mode considering how many people have asked this same question.

#3 You might want to check this:
http://www.ubiqvisuals.com/index.php?option=com_content&view=article&id=55
They have a easy and practical way of controling cameras and other cool functions. It may look a little expensive but it saves you a lot of time and you get great support from the people from ubiq.

#4 Wow, that's a great looking product.

However, It's waaaay too expensive. I would probably purchase T3D if I was going that far anyway. Also, it's for TGEA, which isn't what I'm looking for. There are a lot of T3D features I want to make use of, and reverting to a (albeit gigantic) mod of TGEA doesn't seem like a viable option for me.

Is Ubiq considering a T3D package? I'm assuming their pack would be somewhere in the ~$1200 or more range, which is even MORE out of my price range, but it would be something to think about.

#5 Actually the $ 495 USD version of the kit is for T3D. Right now I think is still on beta version (haven check recently if they upgraded), but if you buy the beta you will get all upgrades for free. We got the beta on our T3D 1.0.1 and its working great. So far we have no camera problems.

#6 Well... talk to me about the kit, since you own it.

Is it easy to strip EVERYTHING out and start a unique project? I don't want half the features they have in the demo, and I don't want to get a headache commenting out functions or function calls for things I can't find and have to trace through hundreds of files to fully disable.

Do I need a professional license for it or can I get away with a Binary as long as I don't get/change the source? I mean, with a ~$500 price tag, they claim to give source access. I don't think i can "partially" compile the engine, so would this be a way of circumventing licensing the professional version? I doubt it, but it's vague. I don't want to get it, then find out I need to get Pro T3D anyway.

Thanks!

#7 Well I would recomend you to read the online tutorials so that you can get an idea of how this kit works:
http://www.ubiqvisuals.com/index.php?option=com_content&view=article&id=62
http://www.ubiqvisuals.com/index.php?option=com_content&view=article&id=61

If you don't want to use something from the kit you don't have to. However, if you install this kit it will change some FPS camera and mouse functionalities and replace them with the 3DAAK functionalities. E.g. Say good bye to the slide movement from the FPS code because you don’t need it any more, the player can move and face any direction. Now it’s really hard for me to know what is going to be useful for you, so I recommend you visiting Ubiq’s support forums and asking them more specific questions.

Regarding the last question you better ask them. What I can tell you is that you have 5 days to test the kit and see if you like it. If not, you can return it and get a full refund.

**if you are unsatisfied with your product Ubiq Visuals Inc. will provide you a full refund within 5 days of purchase.

Hope this helps!

#8 Ok so you want more of a free moving orbital type camera.

Juan I noticed that they are using DIFs with that product, which is something that I was under the impression is being phased out. Do you know if the functions displayed in the video are compatible with dts objects?

Also Daniel, that product looks great, but like you said you're not going to use much of the kit other than the camera. Purchasing the binary of T3D right now will save you 150 in the long run, you may look at saving up for that, as I'm sure the advanced camera resource will be updated to be used with T3D.

It may take you a while to save up, but making all your artwork, models, animations, interface designs takes a lot of time. The project I'm working on now I'm fine with the binary for probably 4 months or so, since I'm doing everything myself and my game functionality won't be implemented until everything else is finished.

#9 Yeah, I'm going to be in that same boat too. I'm primarily an artist, so I know the hours spent fretting about this are hours I could be spending generating the art.

I'm just wondering if the T3D binary is a good choice. I don't want to purchase it if I could just use the demo for free just to get my assets in and test them.

I also won't need anything crazy for my game either. I'm pretty sure it falls under "simple", which is achieved by scripting.

If I get the Binary, and they decide to update the advanced camera for T3D, will I be able to use it? or will it require source editing, and thus a pro license?

#10 Daniel,
The advanced camera is a free resource, but it does require source code access to use. And that ofcourse depends on someone porting it to T3D in the first place.

The binary is great, and is exceptionally great during the month of december while it is only $100. By paying that $100 GG is taking off $250 of the price of the T3D professional. So If you don't own TGEA it's hard to pass up this deal.

You can use the demo for testing your art and making your GUI to an extent. There is a limit on it for how much you can do. I believe it's a 30 object limit, so keep that in mind. If you plan on making your game with T3D, and do not own TGEA, I would buy the binary ASAP while it is $100.

#11 Daniel, I've been hacking away at a 3rd person camera like what you are requesting for over a month. Mine is more like assassian creed's camera (add newtonRotation and you'd have what you're looking for I think) I'm pretty sure there is a way to do it in script, but I run into a block on the turnleft/turnright controlling the camera and the player. IF, you can setup keybindings to do this, I would like to see an example; because I sure can't figure it out. Yes, I can do it in code(use the controlling separate objects resource), but I'd like to figure it out in script since so many people would like to have it.

My idea so far:
use getEulerRotation in the freelook keybind to determine the rotation around the player and activate turnleft/turnright.

Can't get it to work.

Anyone have an idea?

#12 So wait, you've gotten the player to move relative to the camera, but now you can't turn the camera?

I'm not sure what you're saying you haven't done.

EDIT:

Thoughts on camera issues:

Ignore moveMap functions turnRight/Left (for actual movement). Overwrite the moveMap functions for moveLeft/MoveRight and treat them like constant "Update" callbacks. Continually update the camera's Yaw to try to attain "0" rotation (your Euler rotations.)

For the player's movement (also in moveLeft/Right), Have a function to turn the player the direction desired and walk "forward"

The "walk forward" should happen at the same time as the "turn" function so that you can get smooth turning. Although, the turn speed should happen instantly when stopped.

Just thoughts. Not sure if I'm making any sense.

#13 Sorry, I was confusing in my last post.

Im saying that using the camera docs/rts example. The camera is moving "relative" to the player. But my problem is, you can either move the player and not the camera, or move the camera and not the player.
In effect, I need to remove the Alt+C. The mouse controls the camera, the keyboard controls the player. I've been told that you just rebind the movemap and it will work.

I believe a "tethered" camera is possible with a little lag(newtonRotation). It mentions them in the docs, but I was unable to get it to work.
So anyone out there with an example would be great.

Your idea about turning the player is possible. I've made a 3D side scrolling control scheme that turns the player left to right based on eulerRotation. Could be expanded to turn a full 360. Animations, lags and other stuff might present a problem though. I'll have to mess with it.

#14 Well, there are a few things I'd like to hear from either GG employees or very knowledgeable people:

What is the function of the Cam node in a character's DTS Hierarchy? Is it simply where the camera will go to in first person mode? Would it have any use in a 3rd person camera?

Does Orbit Mode turn your character? If not, is there a way to have the orbit follow the player? There don't seem to be complete docs for camera functions and callbacks, so I don't know if there's a way to change the camera's position/orbit origin onUpdate.



More thoughts on Scripted Camera -

left/right movements should turn the camera slowly. Left/Right + down = move camera very quickly.

As for rotation of character, perhaps it should rotate instantly, as opposed to interpolated. Animations SHOULD work no matter what direction the player is facing, right? I mean, rotating the player should rotate the animations unless somethings horribly wrong with the engine. I can't imagine a scenario in which a rotated player needs to snap back to forward or whatever to play its animation.

Now, does the default player have different Left/Right side walk animations or not? I think gideon STILL uses a reversed frame animation (That's just... why????)

J - What problems have you come across with rotating the player independent of the camera? I would think that things like raycasts and animations would still be shown relative tot he transformation of the player.

I would think the code would be as simple as changing the default.binds.cs functions to:

function meoveforward{

Turn player to face forward (relative to camera)
$mvForwardAction = %val * $movementSpeed;

}

and

function moveleft{

Turn player to face left (relative to camera)
$mvForwardAction = %val * $movementSpeed;

}

both the left and forward set the $mvForwardAction, and theoretically, the player will move "forward" relative to the player's eye in both cases.

Anyone see anything wrong with this code?

#15 Cam is the node in a player model that defines where the default 3rd person camera's postion will be from the player.

Orbit mode method defines a rotating(orbiting) camera style around the defined object:
%client.camera.setorbitmode(%object, %camerapostionfromplayer, etc...) see docs.

OrbitMode does not "rotate" the player at all. In order for a functional player using orbitMode you would have to use %client.setCameraObject(%client.camera) and then %client.setControlObject(%client.player), then make sure you're in thirdperson. serverConnection.isFirstPerson(true);

%client is LocalClientConnection


That idea would work for turning the player:
Use the eulerRotation to check and see if the player is facing a certain direction, then just getTransform, then adjust and settransform on the player. Pretty straight forward for that, but you'll be jerking as it switches direction if the camera is following the player in orbitMode. Controlling the player like that seems to be an inefficient way to do things though unless you are only needing two directions...ie: side scroller.

And your animations will play...but I think it would make them look funky jerking when it changes direction. Maybe setup enough turn points inbetween the 90, 180, 270, 0 that it keeps it smooth.

I just feel that the solution is much simpler and is already setup, we've just got to figure it out in script :)

So question to GG...

Player cam:
When in freelook mode on your player's cam the yaw and turnleft/turnright do the same thing.
So, is the yaw and the turnleft/turnright treated as the same in engine? or can you actually separate them in your keybinds? I would very much like to see an example of this please.


Separate camera object in orbitmode:
Can you control the player with keyboard only and the mouse controls the camera only? Is this possible in keybinds or is there some other way? I would like to see an example of this also.

That would solve all my frustation knowing the answer to those two questions.

I'm about to give up and just do it code side and be done with it, lol.

#16 J and Daniel - Hop into our IRC channel, I think we can help you in real time and post the fixes in this thread once it's been worked out.

#17 Where should I meet you? I'm in the #garagemaes channel,

Or rather, when did you mean to meet? next IRC hour?

#18 Working on solutions currently with Michael Perry...

Stay tuned for more info. Current idea: TrackObject and update the camera's position, add in newtonMode/rotation for lag.

#19 Sorry I missed you guys last night. We've been busy with this dang blizzard. Is there a link to the irc script so I can catch up?

EDIT: got my profile updated to recieve IRC hour transcripts. But I'm unsure if I'll recieve previous ones. So probably still need a link if you guys got it. Much Appreciated!

#20 Well, Michael Perry ended up diving head first into the source to see what was going on under the hood. We were thinking about different solutions, but haven't implemented any full fixes yet.

The IRC crashed yesterday evening, and I was unable to connect to see if Michael had gotten anything further accomplished.

Some more thoughts on the camera (J, if you get a chance to try this, let me know):

Last things we discussed were two options - Making the player an AIPlayer, or (and this is one I favor if I can get it to work) Use a camera in TrackObject mode that is scripted to follow the character with newtonMode and newtonRotation enabled.

The problem with orbit mode is that the camera and the player use the same info for turning. In track mode, the camera ignores player input, but is not "locked." Using an Acceleration script, we can tell the camera to "move forward" (and since it's always tracking the player, forward will always be toward the player.)

Hopefully I can catch up with Michael Perry and see what ever came of the IRC chat yesterday.

Problems with the latter: I foresee problems with the camera getting too low. If it's always looking down on the player, it'll lose elevation over time. Perhaps make it maintain a vertical offset from the player?

Also, not sure if there's a quick and dirty way to clamp off any overshoot or "rubberbanding" if the camera tries too hard to catch up or is simply goign too fast.

EDIT: Another concern: Camera Collision. Orbit handles it automatically, theoretically, trackCamera shouldn't. Maybe do a hacky "setPosition with slight offset" on collision?