|
Re: A7 next gen workflow :
[Re: Machinery_Frank]
#160869
11/07/07 19:16
11/07/07 19:16
|
Joined: Jan 2003
Posts: 71 central US
yung
Junior Member
|
Junior Member
Joined: Jan 2003
Posts: 71
central US
|
Alright, I must come forth and say that Ive been working to develop these programs I have mentioned, mainly in theory, sometimes in actual code. As for my solution to tools like cutscene maker etc, I always try to make them as modular and straight forward as possible, and try not to limit the user in any way.I guess the solution was somewhat revolutionary for me at the time; Write our own file formats. Using the file_str/var commands it can be easily done. For the cutscene maker, not only did I want to be able to interpolate the POS' and ANGLES, but I wanted to give the user the ability to interpolate everything else as well, ARC, ASPECT, TRANSPARENCY, etc. The only reason I never released these tools is because there is a bug in my interpolation code. Not always, but everyonce in a while, the camera will do the wrong thing. Here is the problem; Since its KEYFRAMES that are used, my code resolves the direction to travel on a given axis as being the shortest of the two directions to the next keyframe's pos/ang. This works fine if the animator understands that, but in the case where POINT B is farther away in the intended direction than in the opposite direction (think rotation), the object would simply take the shorter direction(go the other way), which is not what was wanted by the animator. Ive tried several different methods, but all have a problem somewhere. For instance, if I dont use ang(); to return wrapped values (-180 to 180) for angles, then Im working with absolute rotational values, and thus the camera/object would do several rotations (spinning) before ending at point b. Its been hard to find the perfect solution. Also, my code is all built on simple arithmetic, and uses functions like: dist_on_axis = getgaps(sourcevalue, destval); to always return either 0 or a positive value giving the distance, because you have to manage the fact that the different positions could cross 0 pos/neg threshold at any time. I am considering releasing some of these tools for further development by myself and others, if anyone is interested in seeing these tools become of real use, let me know. The only real work left to be done on them is to fix the interpolation code so that it always works perfectly. PS: The other problem with my equation is that it uses distance_per_cycle as speed, and if this distance is not within a certain range, problems can occur; Ive resolved this as good as I know how by manually setting the final position if the distance to travel is larger than the distance remaining. Also I still need a final smoothing pass where the movement speed is the same over different distanced keyframes within the same animation.
' The One '
|
|
|
Re: A7 next gen workflow :
[Re: Machinery_Frank]
#160870
11/08/07 07:02
11/08/07 07:02
|
Joined: Sep 2002
Posts: 8,177 Netherlands
PHeMoX
Senior Expert
|
Senior Expert
Joined: Sep 2002
Posts: 8,177
Netherlands
|
Quote:
No. If you want to make an intense game with tons of cut-scenes then you have no chance to program them all yourself. A cut-scene editor is a very nice idea.
All you really need is a small code that records positions and another code that is able to load those at runtime... Cutscene editors are evil, they make things more complicated than they should be in my opinion even at the expensive of workflow. You might end up doing things multiple times if you need the same movement in your game too.
Recording positions, coordinates, angles and so on really isn't that much work once you've written the code to record and playback a cutscene. Moving objects in your game shouldn't be hard to program, besides, that's what you're going to be doing anyways... Next thing you might end up wishing is indeed TUSC,
Quote:
You never can imagine all the states of coordinates, rotates and animation states in your mind to program them in the background.
Which is exactly why recording the movement and so on is the best way,
Cheers
|
|
|
Re: A7 next gen workflow :
[Re: PHeMoX]
#160871
11/08/07 08:42
11/08/07 08:42
|
Joined: Nov 2004
Posts: 7,121 Potsdam, Brandenburg, Germany
Machinery_Frank
Senior Expert
|
Senior Expert
Joined: Nov 2004
Posts: 7,121
Potsdam, Brandenburg, Germany
|
I am quite sure you never worked with a modelling / animation software if you write such a comment. You need more than just recording coordinates. You also have to interpolate between keyframes and sometimes you have to edit some adjustments. I have no problem when some users like you want to program everything themselves. You can do it. Please show me the results. Maybe some other users want to buy it. By the way: It is not very prudent if everyone invents the weel again and again (except for learning purposes but not if you want to make a game). Some other just want to be more productive. So let us talk about the topic: "next gen workflow". I am really sure that you missed this topic a bit since "programming everything myself" is far away from being a good workflow
Models, Textures and Games from Dexsoft
|
|
|
Re: A7 next gen workflow :
[Re: PHeMoX]
#160873
11/08/07 14:07
11/08/07 14:07
|
Joined: Nov 2004
Posts: 7,121 Potsdam, Brandenburg, Germany
Machinery_Frank
Senior Expert
|
Senior Expert
Joined: Nov 2004
Posts: 7,121
Potsdam, Brandenburg, Germany
|
Quote:
..either that or you're just being lazy.
Fortunatelly this is not the case for me. I finished lots of models, texture packs, custom modelling, software programming plus a job and my company.
So I really just want to save time with a good tool-set like others want to do. It makes not much sense if everybody re-invents a cutscene editor themself.
I am even willing to pay for that. It could be very cool if I can make little real-time demos for my model packs just with a handy tool instead of starting to program it for every scene again.
Just ask yourself: Why every bigger modelling/animation package (even the free blender or some game-engines) come with a keyframe timeline editor? They just could tell their customers: Script it yourself!
Models, Textures and Games from Dexsoft
|
|
|
Re: A7 next gen workflow :
[Re: Machinery_Frank]
#160874
11/08/07 18:23
11/08/07 18:23
|
Joined: Jan 2003
Posts: 71 central US
yung
Junior Member
|
Junior Member
Joined: Jan 2003
Posts: 71
central US
|
@ Friendly Frank: I agree with you completely. I know because several years ago, when I first attempted cutscenes, I thought like PHeMoX, thinking I would just script everything hardcoded. Of course, it wasnt long before I realized that this method was not the answer. Even if you did everything by hand, meaning recording every camera position/angle by hand, every objects angles etc, what you would end up with is massive scripts that would consume too much resources, simply by sheer size. In light of this debate, Im going to go ahead and release my cutscene tools to the community. It is under-developed atm, but I'll take a day or two to go back through the code and clean it up, and write a new interface for all the features, since I mainly called all the functions from the command line when I was working with it. PS: I'll post the zip file in User_Contributions thread, so other users will be able to find it, so check there for it.
' The One '
|
|
|
Re: A7 next gen workflow :
[Re: HeelX]
#160877
11/09/07 04:04
11/09/07 04:04
|
Joined: Mar 2006
Posts: 3,538 WA, Australia
JibbSmart
Expert
|
Expert
Joined: Mar 2006
Posts: 3,538
WA, Australia
|
Quote:
Even if you did everything by hand, meaning recording every camera position/angle by hand, every objects angles etc, what you would end up with is massive scripts that would consume too much resources, simply by sheer size.
as much as a cutscene editor would be nice, that quote there is fairly useless, really. by writing a few different interpolation functions and handling styles of camera control, it'd be really easy to have really good cutscenes set up with minimal code. just remember to re-use a lot of functions, and don't be as lazy as the makers of KOTOR (1 & 2) with their awful use of stock animations. each cutscene could easily be no more than a few dozen lines (at most, which is really small) if you write some simple functions to make the cutscene coding cleaner, and put them in an include file.
julz
Formerly known as JulzMighty. I made KarBOOM!
|
|
|
Re: A7 next gen workflow :
[Re: JibbSmart]
#160878
11/09/07 07:02
11/09/07 07:02
|
Joined: Jan 2003
Posts: 71 central US
yung
Junior Member
|
Junior Member
Joined: Jan 2003
Posts: 71
central US
|
@ JulzMighty: The way I visualized what Phemox was talking about was refering to hardcoding each cutscene specificly, meaning in functions setting each property individually, like a line by line script execution. Therefore, what your doing lies at the other end of the spectrum, and if you've got your own system for "interpolating" recorded waypoints, then that is exactly the same as keyframes, and: if A==(recorder + playback) + fileexport(loaded for playback,interpolation)) then you are using keyframes and {A = cutscene_editor.}
' The One '
|
|
|
|