Cinematic Editor: Devlog#2

Hi
The good news is that the exams are finally up and summer vacations are on, so I can spend all my time coding ! :smiley:
I started working from 31st night and till 20th June, I’ll be focusing on the following GUI features :
• Cinematic Layers + Keyframe Types
• TimeSlider UI
• Playback Control Ui
• Scene Viewer Integration
• Add/Remove Layers
• UI Base
You can read more about them in the US doc. I believe this should also prepare a basic framework for the editor to communicate with the cinematic API.
I started by building upon the prototype’s UI . i.e. splitting a swing JTable into a fixed part (for displaying static info like Object name/type/lock etc) and a horizontally scrollable timeline part (for representing frames). But it was becoming too messy to incorporate a time-slider, drag/drop feature or event resizing feature through this approach, so I dropped the idea.
The new approach is as follows : I have a JPanel called the TimelineCanvas (width depends on duration and height depends on no. of layers) which holds all the CinematicLayers in a Top to Bottom manner (i.e along BoxLayout.PAGE_AXIS). Each layer represents an object in the cinematic clip e.g spatial/gui/audio etc. The layers themselves are JPanel’s whose width is equal to the width of the canvas and have a fixed height (height of canvas = height of layer*no of layers). Each layer represents a row in the TimelineCanvas. The Layers can hold Events and each event is represented as a JPanel whose height = height of layer, width depends on the duration and position depends on its start and end time of the event.
The TimelineCanvas will act as the view of a JScrollPane’s viewport. The ColumnHeader of the JScrollPane will represent a Time Scale and the RowHeaderView will be a JTreeTable (or a custom TreeTable) to represent the static info(like Layer Name/type/visibility/lock-unlock etc). This is just a quick overview of how I am proceeding with the UI. I think this should work fine, but I’d really like some more thoughts on it
I need some help with the following :
Everytime I change the code and want to see the changes, I run the module from the SDK, which then opens up a new Netbeans window where I see the changes. This process takes quite some time as I need to run the module frequently to make the GUI look appropriate. I hope there is a better way to do this !
To save time, I am coding the GUI in a separate Netbeans Java Application Project called the Cinematic_Editor_GUI_Assist. This is the reason why my commit activity on the main repo has been little.
I’ll be needing custom event listeners soon, could you share some ideas about how to code them??
The request a feature form is still up .You can suggest some cool features that can make the cinematic editor great!
I’ll wrap up this devlog with the name suggestion tradition :stuck_out_tongue: . I was contacted by jovlem via Youtube. He put forward some really cool names : Ani-Monkey, Monkey-frame ( keyframe) or Mon-keyframe, Monkey’s motion, Jmon-Keyframe-Editor. He also suggested a way to blend animation channels of a character : see this

1 Like

You can run the module in the development IDE.

@normen said: You can run the module in the development IDE.
uh really ? :( i didn't even knew...

@Mayank I like “Monkey-frame”, but I would more write it “MonkeyFrame”.

What do you mean by custom event listener? what’s the use case?

About the animation blending, JME’s animation system does not support it right now. And I guess it’s a bit out of the project scope. But that’ll be cool to have something like this indeed.

@nehon said: uh really ? :( i didn't even knew...

Yeah, you gotta use the SDK then though so that theres all the other needed plugins. I still like running the plugin in a separate application with its own settings etc. though. But I don’t have to run my application on every changed code line because I don’t need to create GUIs from code :slight_smile:

Personally, I like Ani-Monkey way better than Monkey Frame. Though neither of them make me think “That’s the one!” Though C-Monkey (for Cinematics Monkey) makes me chuckle because of Sea Monkeys… I don’t think it’s very clear, though. :slight_smile:

May a stupid suggestion, why not use javaFx for GUI ? There are other plugins (like ShaderNodeEditor), that “theroricaly’” (not tested myself) should be easier to draw/manage with javaFX than with Swing + Canvas. Form this slides it’s possible https://oracleus.activeevents.com/2013/connect/fileDownload/session/7876D121B0C32B74AF0E56E8D5151BD6/TUT3869_Anderson.pptx

Well…didn’t occur to me that you could. I personally often use the UI editor for SDK UIs idk if it works with java fx.

Well since netbeans is swing, and javafx can be integrated into a swing application, at least technically this should work fine.

@normen said: You can run the module in the development IDE.
@normen running the module in the SDK or the IDE is taking the same amount of time. Running the 'netbeans java application' is much faster ;)

@david.bernard.31 : I have looked into javafx, it seems pretty cool for UI development. The looks are better, its MVC, the logic is completely separated from the front which uses CSS +we can animate the UI and it should work with Netbeans acc to the ppt. Although I haven’t used javafx much, I feel it can really improve the UI. @nehon Should I migrate to javafx or continue with swing? I’ll need around 2-3 days to get comfortable with javafx and start using it for the project. But it’d mean losing 7 days of work :stuck_out_tongue: . To be on the safe side, I think I should continue with swing and if there’s time left or after GSoC I can migrate to javafx. What say??

@Mayank, well I guess it could really improve the UI. If you switch better sooner than later IMO, so if you feel you can do it, go ahead. But don’t keep it for the end, because the migration cost will be a lot higher.

Is javafx available for Java 1.6? Do we care in the SDK itself?

@pseed : It’s available for JDK 1.6 , but JDK 1.7 is recommended. There might be deployment issues on Linux and Mac with JDK 1.6. http://docs.oracle.com/javafx/2/installation_2-2-5/javafx-installation-windows.htm#A1197821. I’ll have to look into it for more details
Also, I have set the source level of the cinematic_editor module to 1.7 (right-click on module-> properties->Sources). Should I bring it down to 1.6 or do plugins with source levels different from the SDK work?

@pspeed : it should work fine with JDK 1.6 theoretically ! All I can find is that we can’t deploy as a self-contained application with 1.6.

jdk 1.6 is javaFX, jdk7 is javaFX2.0. Only big difference I can find is that you can build tour UI with java in 2.0 instead of using an fxml file.
Maybe @Empire_Phoenix or @abies can comment on this since they seems pretty familiar with javaFX.

The JavaFX scene builder is probably the safest bet here. It’s produced by Oracle, so yeh… That said, so was that awful update which completely wrecked applet designing for indie developers.

javafx 1 is dead.
javafx 2 works with jdk 1.7, but jdk 1.8 is better match (thread model, closure,…) and ease integration with netbeans 8. Take a look at the slides I previously linked. I didn’t try myself, so I can’t advice.

I don’t know the target platform for SDK 3.0 or 3.1, I hope it doesn’t need to match the same constraints than jme runtime. Currently jme 3.0 runtime should run on jdk 1.5 from doc and config of plugins (I’m new to jme).


Answers better than I can, why do we still need to support 1.6 for the SDK btw?
Is there any platform holding us back?

The Fx Scene builder is just really great, it’s so far the best application I have seen that can do such a thing.
-> Exspecially since the fxml files are actually really possible to work with directly as a human, and are strongly specified, so breaking changes are unlikly.

Btw the docs seem to be outdated, jme is actually 1.6 targeted.

Edit: Put the reply, waited 1 hours before pressing submit and it turned out there are 2 answers above saying same things, so nothing to see here, move along.

The engine is currently based on Java 1.5, the SDK on 1.6. For 3.1 the engine will have Jva 1.6 as baseline and the SDK 1.7 or maybe even 1.8 for the SDK, depending on when it comes out.