PvModelViewerG3d

[uuu]

Hi,

I have been playing with Java little bit, and small program "PvModelViewerG3d" is result of it. It currently supports only g3d (version 3 and 4). It does not support particles, maps, or anything else except g3d models.

G3d file format specification / description
G3d version 4
G3d version 3

It should run on: windows, macosx, linux.
It runs on: windows vista 32-bit, windows 7 64-bit + java 32-bit, linux 64 bit + java 64-bit.

Issues
indian tent looks weird - Z-zoom isn't as expected? and Z-rotation (of model-view) should default to the same value as in Glest

Feature requests
- when manually changing animation stage, it should jump through end/begin (0.98, 0.99, 0.00, 0.01, ...)
(added)
- the axis text (X, Y, Z) should not scale while zooming
(added)
- add pause/resume camera movement option
(added)
- use mouse for camera movement (wheel for zoomin, buttons for rotation)
(added)
- g3d version 3 support
(added)
- reset the camera position
(added)
- keyboard shortcuts: +- zoom, pause pause/resume camera animation, backspace reset camera, spacebar pause/resume model animation
(added)
- add settings for speed like in Glest: speed in seconds = ceiling(1.0/(speed in glest/4000.0))/40.0
- add support for Z-X grid
- grid should default to "Glest tile size" in density (but how?)
- add drag & drop support
- remember last-used settings
- remember last-used directory, remember recent-files list

Example g3d files version 4
MegaGlest/techs/megapack/factions/egypt/units/snake/models/snake_standing.g3d
MegaGlest/techs/megapack/factions/tech/units/battle_machine/models/battle_machine_attacking.g3d

Example g3d files version 3
MegaGlest/techs/megapack/factions/indian/units/archer/models/archer_walking.g3d
MegaGlest/techs/megapack/factions/indian/units/horseman/models/horseman_attacking.g3d

Tell me what you think, and if it is of any use to anybody. Maybe you would like to have more features? E.g. more formats, make it map viewer too, etc.

If it doesn't start correctly:
(A) it complains about missing library: run it with "java -Done-jar.verbose=true -jar PvModelViewerG3d-all.jar > log.txt" and send me file log.txt
(B) it complains about other error - just say so

Dependencies of program: none (except standard Java 6).

Screenshot:


Download: http://trampolina.hys.cz/MG/my/PvModelViewerG3d/PvModelViewerG3d-all.jar

Cheers!

[wciow]

Nice work 

Sadly I can't test it as I'm using Ubuntu 12.04 + OpenJDK6, which just spits out a string of errors 

[tomreyn]

I'm also on Ubuntu 12.04, x86_64 here:

Code: [Select]

tomreyn@atibox$ java -version
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-1ubuntu0.12.04.1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

For convenience I've written a two-liner wrapper script, PvModelViewerG3d:

Code: [Select]

#!/bin/sh
 java -Done-jar.verbose=true -jar PvModelViewerG3d-all.jar 2>&1 | tee PvModelViewerG3d.log
 
The application fails here, too, and I've uploaded said string of errors as captured in a logfile.

It's nice that you are becoming creative.

Edit: This time I actually ran it correctly.

[MightyMic]

Works for me... good job

Win 7 - 64 bit

[uuu]

Thanks for feedback.

MightyMic: thanks, I added Win 7 to OS where it runs.
tomreyn: thank you, your program was helpful. I hopefully fixed the packaging problem, could give it a try (download and run again)?
wciow: could you give it a try again? I re-packaged it.

[uuu]

It's nice that you are becoming creative.

Well, I was creative programmer before, and also creative MegaGlest player 
The truth is, I like statically typed object-oriented programming languages (as they are superior), namely C++, C# and Java. I wouldn't like to spent too much time with cross-platform compiling with C++, Linux guys here wouldn't appreciate my skills with .NET 3.5  and ... Google vs Oracle lawsuit about Java ended just little time ago. So here I am

[tomreyn]

Thanks for the update. PvModelViewer starts up fine for me now, consuming 27 MB resident memory - way less than I had expected. My last-but-one generation quad core CPU is 3% busy when running it - whether or not a model is loaded. I assume this could possibly be reduced a little at the expense of more RAM (more caching?).

Something seems to be wrong about the last stage of an animation. When I use the battle_machine_attacking.g3d model, and manually switch between stages 0.99 and 1.00 I get a very differently presented model.

For feature requests (if I may), I'd like to see:

• zooming by mouse wheel and keyboard controls (e.g. using +/- by default)
• moving the camera using drag + drop or keyboard controls (e.g. using cursor keys by default)
• a button and keyboard control (pause key?) to pause/resume the camera movement, i.e. if a delta is set
• a button and keyboard control (backspace?) to reset the camera position
• a button and keyboard control (space bar?) to pause/resume the animation, i.e. if a delta is set
• the axis text (X, Y, Z) should scale while zooming
• Possibly Ctrl-Q or similar keyboard shortcut for quitting (I guess Alt-F4 can be good enough, though, and already works for me)

About the G3D v3 format specification - Martiño posted it years ago.

[uuu]

Thanks for the feedback. Linux 64-bit added to OSs that are working as expected.

Issue(s) and feature requests added to the topic, I will keep you posted on updates.

[uuu]

About the G3D v3 format specification - Martiño posted it years ago.

Thank you for the link, I added support for g3d version 3 file format, download and test after it's status is "added" ("added, coming soon" means I didn't upload it yet).

[uuu]

Thanks for the update. PvModelViewer starts up fine for me now, consuming 27 MB resident memory - way less than I had expected. My last-but-one generation quad core CPU is 3% busy when running it - whether or not a model is loaded. I assume this could possibly be reduced a little at the expense of more RAM (more caching?).

"premature optimization is the root of all evil"  The code is intentionally left very clean (of any caching), because it's goal is to load and draw just one model (and few other things, like grid, xyz axis), so the performance is less important than maintenance (e.g. easily adding new formats, features).

Yes, you are right, caching could be used. Also consider the FPS settings - it really draws (unless it can't because of cpu/gpu) selected amount of frames per second, so it does work all the time, no idling.

Note that also drawing is made the simplest possible way (glBegin+gVertex...+glEnd instead of glDrawElements), so there is performance degradation for that, too (gpu, cpu).

Note that also data structures are made to be easy-to-use, rather than efficiency.

I also used float64 everywhere instead of (probably sufficient) float32.

GUI part (dialog) should be considered into memory usage, too, SWING is nice and convenient and has platform-independent look (or it just simulates platform), but has some memory costs.

E.g. here with loaded model:
- 100MB total memory: 60MB private, 40MB shareable. And that is, let's be honest, memory hog.
- 4% CPU consumption, 0% CPU if window is minimalized. I guess the 4% CPU is thanks to over-simplistic drawing. Even Java is smart enough to calculate few floating point operations (triangle interpolation) as fast as it is possible - that's why Java rocks in benchmarks (and thanks to memory might suck at real life).

[Omega]

It'd be useful to have a more technical G3D viewer. However, some constructive criticism on how the program could be improved: Firstly, the viewer seems to use a unique speed per second and FPS setting, rather than use the same formula as Glest does for animation speed. Using the same numbers could allow modders to easily get the "perfect" animation speed. The mouse navigation seems to be very constrained. While I can move the camera with the input boxes freely, I can only rotate on the z-axis with the mouse. As well, scrolling with the mouse wheel seems very slow. Next, there is the scale of the model, especially compared to the grid. I'd rather the grid be in Glest "units", so we can easily see if the unit is, for example, a size one unit. Rather than allowing us the change the size of the grid, I'd rather we get just an option to toggle the grid on or off. I can't think of any reason to need to resize the grid. I suppose being able to increase the density may be useful, for extremely large models, but the size of each square should be a single "Glest unit". In fact, an interesting feature to add would be a toggleable vertical grid (along the z-axis), which would make it easier to see the unit's height in Glest units.

On another note, opening a model uses the gawd-awful "common files dialog", rather than the more modern "explorer-based file dialog". I don't know if there's a cross-platform method of choosing the alternative in Java, but if there is, it would be extremely useful to switch to the more modern variant, if possible, to prevent Windows peeps from having to either cope with the lousy file browser or switching to explorer to copy the file path.

Finally, is this open source? If so, what license is this under and where can the source be downloaded?

[uuu]

It'd be useful to have a more technical G3D viewer.

I didn't quite understood, is this more technical G3D viewer, or you would need something else?

Firstly, the viewer seems to use a unique speed per second and FPS setting, rather than use the same formula as Glest does for animation speed.

"second" isn't very unique, it's actually official unit for time. I know nothing about unique Glest formulas for animation. 

The mouse navigation seems to be very constrained. While I can move the camera with the input boxes freely, I can only rotate on the z-axis with the mouse.

Exactly. I did this intentionally. I like to keep things with camera simple - I always end up looking at the wrong direction.

As well, scrolling with the mouse wheel seems very slow.

I am not sure, maybe the mouse wheel speed is platform specific? What is your platform? What means "slow"?

Next, there is the scale of the model, especially compared to the grid. I'd rather the grid be in Glest "units", so we can easily see if the unit is, for example, a size one unit.

This is interesting, because (1) I am not sure how long your Glest unit is, and (2) models are not scaled, so e.g. if grid is 2x2 size and your model is 2x2 size, it's the same size, so it is "Glest" units, is it not?

Rather than allowing us the change the size of the grid, I'd rather we get just an option to toggle the grid on or off.

Yes, it's called option "draw the grid", it's checkbox, please, try clicking it 

I can't think of any reason to need to resize the grid.

So don't

In fact, an interesting feature to add would be a toggleable vertical grid (along the z-axis)

It might look a bit weird, maybe it would be better to draw ruler (without numbers) on each axis? Or show info about model XYZ sizes? What would you like to have?

On another note, opening a model uses the gawd-awful "common files dialog", rather than the more modern "explorer-based file dialog". I don't know if there's a cross-platform method of choosing the alternative in Java, but if there is, it would be extremely useful to switch to the more modern variant, if possible, to prevent Windows peeps from having to either cope with the lousy file browser or switching to explorer to copy the file path.

As far as I know, Java windows (Swing) and dialogs are platform independent, so they might look a bit strange (non-native), but the behavior is consistent among platforms. You might have noticed, that e.g. buttons are not the native buttons either. Maybe it would be enough to add support for drag & drop, so you could use your favorite file browser easily?

Finally, is this open source? If so, what license is this under and where can the source be downloaded?

Well, I usually don't start writing license before writing first line of code  As the post says, I wasn't sure if it is useful for anything for anybody.
a) I am not sure yet, I haven't done anything public yet, I was thinking about revised BSD, MIT, Apache or something similar.
b) there is no javadoc whatsoever, source code is 100% the same as decompiled *.jar, it's not obfuscated or anything

[Omega]

"second" isn't very unique, it's actually official unit for time. I know nothing about unique Glest formulas for animation. 

The formula for how Glest translates the animation speed into an actual unit of time can be found here.

Exactly. I did this intentionally. I like to keep things with camera simple - I always end up looking at the wrong direction.

Sounds logical. Except it's ridiculously difficult to examine the top of a model, for example. Perhaps you could have the other mouse buttons have different functions. For example, holding the LMB could move along the z-axis (as it currently does), while the RMB could move along the x-axis and the MMB would zoom.

This is interesting, because (1) I am not sure how long your Glest unit is, and (2) models are not scaled, so e.g. if grid is 2x2 size and your model is 2x2 size, it's the same size, so it is "Glest" units, is it not?

Well, take a look at this image. The image on the right shows the MegaGlest G3D viewer. We can tell from the grid that the tent is about size 3. But on your viewer, there's an issue. Not only is the grid completely arbitrary, but the model isn't displaying correctly. The texture seems to be backwards and the model is noticeably distorted.

Rather than allowing us the change the size of the grid, I'd rather we get just an option to toggle the grid on or off.

Yes, it's called option "draw the grid", it's checkbox, please, try clicking it 

Haha, yes, I noticed that. What I mean is that the range and density don't really help modders at all, since the grid is arbitrary. The squares don't mean anything at all. In the G3D Viewer, each square is equal to one tile in game, so that grid has meaning. The density and range options therefore seem rather useless; just the toggle on or off is of use (as screenshots of a unit would generally be done without the grid, for aesthetic purposes).

In fact, an interesting feature to add would be a toggleable vertical grid (along the z-axis)

It might look a bit weird, maybe it would be better to draw ruler (without numbers) on each axis? Or show info about model XYZ sizes? What would you like to have?

I dunno, but provided the grid uses Glest units, a toggleable grid on the z-axis, by default off, wouldn't really look weird. After all, we have to model in Blender with the grid going "up the unit" (since the G3D exporter uses a different orientation than Blender does).

As far as I know, Java windows (Swing) and dialogs are platform independent, so they might look a bit strange (non-native), but the behavior is consistent among platforms. You might have noticed, that e.g. buttons are not the native buttons either. Maybe it would be enough to add support for drag & drop, so you could use your favorite file browser easily?

Drag and drop support would certainly be very useful.

[uuu]

The formula for how Glest translates the animation speed into an actual unit of time can be found here.

Ok, I added to requested features.

Exactly. I did this intentionally. I like to keep things with camera simple - I always end up looking at the wrong direction.

Sounds logical. Except it's ridiculously difficult to examine the top of a model, for example. Perhaps you could have the other mouse buttons have different functions. For example, holding the LMB could move along the z-axis (as it currently does), while the RMB could move along the x-axis and the MMB would zoom.

Actually, I think it rotates around Z axis, not moves along Z axis. Maybe RMB could do X axis rotation?

This is interesting, because (1) I am not sure how long your Glest unit is, and (2) models are not scaled, so e.g. if grid is 2x2 size and your model is 2x2 size, it's the same size, so it is "Glest" units, is it not?

Well, take a look at this image. The image on the right shows the MegaGlest G3D viewer. We can tell from the grid that the tent is about size 3. But on your viewer, there's an issue. Not only is the grid completely arbitrary, but the model isn't displaying correctly. The texture seems to be backwards and the model is noticeably distorted.

I shall look into that. Added to the issues. Thanks.

... In the G3D Viewer, each square is equal to one tile in game...

Ok, added to the feature requests. If you know it by heart, it would help to know, what exactly is the glest grid size?

... a toggleable grid on the z-axis, by default off, wouldn't really look weird...

Added to the feature requests. However, it will be added after the XY grid looks the way you want it ("glest tile units") by default.

As far as I know, Java windows (Swing) and dialogs are platform independent, so they might look a bit strange (non-native), but the behavior is consistent among platforms. You might have noticed, that e.g. buttons are not the native buttons either. Maybe it would be enough to add support for drag & drop, so you could use your favorite file browser easily?

Drag and drop support would certainly be very useful.

Ok, added to the feature requests.

[Omega]

Actually, I think it rotates around Z axis, not moves along Z axis. Maybe RMB could do X axis rotation?

What I meant, yeah. And rotation around the x-axis with RMB sounds right. Having the MMB zoom in (in the same matter as the RMB zooms in the MegaGlest G3D viewer) could also be useful as an alternative to scrolling.

If you know it by heart, it would help to know, what exactly is the glest grid size?

Sorry, I haven't a clue how it works on the programming end. However, all the G3D viewers and engines scale the models the same way.

[tomreyn]

If it doesn't start correctly:
(A) it complains about missing library: run it with "java -Done-jar.verbose=true -jar PvModelViewerG3d-all.jar > log.txt" and send me file log.txt

This will probably not work well on Linux, since it would only capture standard output, not standard error. I think you want this on Linux, so that error messages are redirected to the file, too:

Code: [Select]

java -Done-jar.verbose=true -jar PvModelViewerG3d-all.jar > log.txt 2>&1
Something seems to be wrong about drag and drop rotation using the mouse. It seem like, as son as you click and hold down the mous button and move it just a little bit, the model can rotate a lot instantly, possibly depending on where you clicked (i.e. the distance from the Y axis may be making a difference - it's a bit hard to tell what exactly is wrong there).

For another issue, maximzing the window does not resize or reposition the area in which the animation is played back. I.e. you may reisze your window and the anmiation will only play bakck in the bottom left corner of your screen, and some of the animation will be cut off in frames where it surpasses the area where the animation actually takes place (which is not the entire black area but just a part of it).

Finally, like Omega, I'm also missing X axis rotation.

And for new features, I suggest adding particle support.

[uuu]

If it doesn't start correctly:
(A) it complains about missing library: run it with "java -Done-jar.verbose=true -jar PvModelViewerG3d-all.jar > log.txt" and send me file log.txt

This will probably not work well on Linux, since it would only capture standard output, not standard error. I think you want this on Linux, so that error messages are redirected to the file, too:

Code: [Select]

java -Done-jar.verbose=true -jar PvModelViewerG3d-all.jar > log.txt 2>&1

Actually, standard input, output and error streams work quite the same among the platforms. The "verbose" setting means it logs stuff to the standard output, and it's really what I needed.
To be honest, I was testing new way of deployment (one file looks nicer), so it should be solved/working now.