Messages

726

Feature requests / Re: Random Tilesets

« on: 27 December 2010, 08:44:23 »

I think this is a great idea

The drop-down tileset menu can include the "random" option, for those of us who want to be surprised

727

Mods / Re: Glest unit index (image heavy)

« on: 27 December 2010, 06:53:01 »

Those cards are how I want the context menu on the right to look when you select a unit!

728

General discussion / Re: Targeting idea? Multi-unit targeting.

« on: 23 December 2010, 12:48:19 »

All touchpads are an awkward compromise.

Ctrl and shift modifiers are fairly normal, as is holding a mouse down and dragging a selection.

The key thing is, everbody likes the idea of a group target instead of only being able to target individuals.

729

General discussion / Re: Targeting idea? Multi-unit targeting.

« on: 23 December 2010, 07:19:58 »

If left mouse button selects units and right selects targets for those units...

It seems natural that holding down right mouse and dragging selects all in quad,  right click with shift or control does multiple selection etc?

730

General discussion / advice about artwork

« on: 22 December 2010, 19:00:24 »

Is it a professional trick to add fake shadows or brown feet to models?

http://gamedev.stackexchange.com/questions/6695/game-models-that-stand-in-grass/6743#6743

731

General discussion / A xmas present

« on: 22 December 2010, 13:58:56 »

With much prompting by silnarm, I got pure GPU-side animation going.

g3d_stats.py at

Code: [Select]

[url=https://github.com/williame/GlestToolsy]https://github.com/williame/GlestToolsy[/url] includes a renderer, and this renderer stores all frames and the indices and normals and such in VBOs.

When drawing a model, it sends the one of the frames and the normals through as usual - glVertexPointer and glNormalPointer - but then sends the other frame through as glColorPointer (and you might find space for the normals in glSecondaryColorPointer or something).

The vertex shader now does the interpolation e.g. gl_Position = gl_ModelViewProjectionMatrix * mix(gl_Vertex,gl_Color,lerp);

Shockingly easy, but shocking too how I struggled to solve it. I hope this gives inspiration.

Now I'm off on for a holiday break, and whilst I don't doubt I'll sneak a peak at the forums, me coding this in GAE will have to wait until the new year.  Unless anyone else wants to implement this in the meantime *wink* *wink*

732

General discussion / Re: To Do List & Bugs

« on: 21 December 2010, 10:15:01 »

In the svn trunk 1049, if you triple or quadruple click in quick succession on a unit command icon you crash; e.g. click on a worker, click on the build command, and then tripple-click on the farm icon quickly.

it seems that:

Code: [Select]

glestadv(Glest::Entities::Faction::reqsOk(Glest::ProtoTypes::CommandType const*) const+0x14) [0x61c3f6]
glestadv(Glest::Gui::UserInterface::mouseDownDisplayUnitSkills(int)+0x350) [0x6ab154]
glestadv(Glest::Gui::UserInterface::commandButtonPressed(int)+0x84) [0x6a889e]
glestadv(Glest::Gui::Display::mouseUp(Shared::Platform::MouseButton, Shared::Math::Vec2<int>)+0x28f) [0x6bf1c7]
glestadv(Glest::Widgets::WidgetWindow::eventMouseUp(int, int, Shared::Platform::MouseButton)+0x9a) [0x8021e4]
glestadv(Shared::Platform::Window::handleEvent()+0x153) [0x882989]
glestadv(Glest::Main::Program::loop()+0x2b7) [0x6d06a5]
glestadv(Glest::Main::glestMain(int, char**)+0x35c) [0x6cca71]
user_interface.cpp:872 in mouseDownDisplayUnitSkills(), m_display->getCommandType(posDisplay) can return NULL.

I put a printf in there and confirmed that, but simply avoiding that dereference only makes more pop up instead and it still crashes only later:

Code: [Select]

glestadv(Glest::Gui::UserInterface::giveOneClickOrders()+0x84) [0x6a9f6c]
glestadv(Glest::Gui::UserInterface::mouseDownDisplayUnitSkills(int)+0x5e9) [0x6ab3ed]
glestadv(Glest::Gui::UserInterface::commandButtonPressed(int)+0x84) [0x6a889e]
Therefore, I guess there is a deeper bug in how the command type can be NULL in the first place?

A simple return stops the crash, but is this just hiding a deeper problem?

Code: [Select]

} else {
const Unit *unit= selection.getFrontUnit();

if (selection.isUniform()) { // uniform selection
if (!m_display->getCommandType(posDisplay)) {
std::cerr << "WTF" << std::endl;
return;
}
if (unit->getFaction()->reqsOk(m_display->getCommandType(posDisplay))) {
activeCommandType = m_display->getCommandType(posDisplay);
activeCommandClass = activeCommandType->getClass();
} else {
posDisplay = invalidPos;

733

General discussion / Re: Rendering G3D using OpenGL

« on: 14 December 2010, 08:42:22 »

On account of the above, VBOs for units is not going to work, all those frames of vertex data is far too much to be putting in video memory.

That is my major motivation for looking for duplication to de-dupe.

And of course I'm using integrated graphics, so filling up the RAM I free with computed level-of-detail alternatives is good stretch goal...

So here are some stats from my script the whole of magitech:

=== Input ===
520 models
3314004 vertices in (75.9 MB)
1045767 indices in (4.0 MB)
1818991 vertices out (41.6 MB)
1045767 indices out (4.0 MB)
134520 matrices out (8.2 MB)

There are plenty of tricks its missing, and potentially lots of bugs and false-positives that it would have to avoid deduping.  But I think the overall number is indicative unless it also starts to merge models.

So it can go from 80MB down to 50MB.  However, on reflection, 80MB isn't so scary for geometry?  What's keeping us out of VBO territory today other than writing the code?

734

General discussion / Re: wicker behemoth animation

« on: 13 December 2010, 23:38:25 »

http://www.moddb.com/games/glest/videos/wicker-behemoth

thx John!

735

General discussion / Re: wicker behemoth animation

« on: 13 December 2010, 23:30:41 »

Would YouTube suffice?

Tried to create an account:

Sorry. Based on the information you have submitted to us, you are not entitled to register for YouTube.com.

Quite what it was they didn't like about my info I am unsure...

736

General discussion / wicker behemoth animation

« on: 13 December 2010, 23:21:20 »

Interesting trivia: wicker_behemoth_morph.g3d contains 10 sets of texture coordinates, and if each frame is rendered with the appropriate coordinates then the body glows with an inner fire effect.

The game engines don't seem to show this though.

Presumably it worked at some point once when the model was originally made?

(There are no other models that use this 'feature' that I have found; anybody know anything about it?)

If anyone has anywhere to host a 100KB video, I have what the effect looks like as an AVI.

737

General discussion / Re: Cloaking

« on: 13 December 2010, 22:52:57 »

In C&C Tiberian Sun one or two units could cloak, and when they did they would just shimmer for their owner, whilst not be drawn for their opponents.

They could get detected if they got really close to the enemy, and they had to uncloak - and be defenseless whilst uncloaking - before attacking.

Of course the second point is about rules and balance, not the kind of restrictions you put in the code...

738

Tools / Re: glest_mod_pack.py

« on: 13 December 2010, 22:48:38 »

Now updated to (hopefully, untested) work with Python 2.5 and perhaps lower:

https://github.com/williame/GlestTools

739

General discussion / Re: To Do List & Bugs

« on: 13 December 2010, 17:33:00 »

Oh I'm not complaining about the stacktrace, was just thinking I was missing something obvious

My profiling sadly says my cpu spends all its time in an opaque blob called i915drm which isn't so descriptive

740

Bug report / does the hand of the swordsmen pass through his shield when he's charging?

« on: 13 December 2010, 12:32:27 »

in the tech faction, does the hand of the swordsmen pass through his shield when he runs?  Has anyone noticed this before?

741

General discussion / Re: To Do List & Bugs

« on: 13 December 2010, 09:51:50 »

Building 0.3.2 from source, I have some diverse questions:

0) the bz2 source contains a CMakeCache.txt file; you want to strip that, people will have to know to delete it before building otherwise since it seems to think the user name is James ;

1) unpacking megapack_v4/glest/* into addons/megapack_v4/, the scenarios didn't turn up.  Has the directory name for the scenarios changed?

2) trying to run the 'benchmark1' (MG?) scenario that I found in another thread, it couldn't find tech/megapack/resources, so I symlinked tech/megapack_v4 to tech/megapack and got it to go further, but then it crashes.

My question is twofold then:

2a) how to benchmark graphics performance?  (I want to track it before and after any changes I introduce)

2b) how to get debug symbols in the gae-crash.txt?  My gae-crash.txt is:

Code: [Select]

Crash
Version: Advanced Engine 0.3.2_dev_edition
Time: Mon Dec 13 09:39:26 2010
Description: SIGSEGV: address not mapped to object
Address: 0x8
Backtrace:
glestadv(_ZN6Shared8Platform24PlatformExceptionHandler7handlerEiP7siginfoPv+0x33a) [0x881096]
/lib/libpthread.so.0(+0xfb40) [0x7f68406deb40]
glestadv(_ZN5Glest10ProtoTypes11FactionType4loadEiRKSsPKNS0_8TechTreeE+0xb3) [0x77c55f]
glestadv(_ZN5Glest10ProtoTypes8TechTree4loadERKSsRKSt3setISsSt4lessISsESaISsEE+0x59b) [0x737699]
glestadv(_ZN5Glest3Sim5World8loadTechEv+0xdc) [0x8196a6]
glestadv(_ZN5Glest3Sim19SimulationInterface9loadWorldEv+0x129) [0x838d13]
glestadv(_ZN5Glest3Gui9GameState4loadEv+0x3e5) [0x65956d]
glestadv(_ZN5Glest4Main7Program8setStateEPNS0_12ProgramStateE+0x72) [0x6decee]
glestadv(_ZN5Glest4Menu17MenuStateScenario10launchGameEv+0x175) [0x70ef11]
glestadv(_ZN5Glest4Menu17MenuStateScenario6updateEv+0xe0) [0x70ed90]
glestadv(_ZN5Glest4Menu8MainMenu6updateEv+0x8c) [0x71141e]
glestadv(_ZN5Glest4Main7Program4loopEv+0x1d1) [0x6de5b9]
glestadv(_ZN5Glest4Main9glestMainEiPPc+0x377) [0x6dabd0]
glestadv(main+0x72) [0x6dae06]
/lib/libc.so.6(__libc_start_main+0xfe) [0x7f683ec56d8e]
glestadv() [0x5f00a9]

I edited CMakeList.txt and

Code: [Select]

set option(GAE_DEBUG_EDITION "Enable debug edition extensions." ON) and I then rebuilt clean and I can see my CMakeCache.txt includes

Code: [Select]

CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g but no debug symbols in the stack trace anyway

742

General discussion / Re: Rendering G3D using OpenGL

« on: 11 December 2010, 23:20:59 »

Here is another view of the catapult attacking something:

Code: [Select]

[img]http://img151.imageshack.us/img151/3180/glest1.png[/img]
All the normally-rendered meshes are meshes that haven't changed that frame (other than rotation/translation).  They are animation frames we can represent by matrices (smooth spinning here we come!).  This will save buckets of RAM (hopefully).

The red meshes are meshes which, in that frame, change compared to the previous frame.  The green parts of the mesh are parts that, compared to the previous frame, don't change (other than rotation/translation).  Although this shot doesn't show much green, my idea is to split that out into a separate mesh.  Saving a bit more RAM hopefully.

Here's a norse crossbow attacking something, and it shows the large unchanging parts of the mesh that could be split into separate meshes:

Code: [Select]

[img]http://img219.imageshack.us/img219/6836/glest4.png[/img]
And some of the red looks like float precision problems in my comparison.  I'll have to tweak that.

Here is a humanoid:

Code: [Select]

[img]http://img30.imageshack.us/img30/797/glest2.png[/img]
There is a bit more green.  But the thing that strikes me is the symmetry; I will add a check to see if parts of a mesh can be represented by reusing parts of the mesh - or another in the model - with a matrix.  If things are as symmetrical as they seem, this will save buckets more RAM.

Finally, lets peep under that skirt:

Code: [Select]

[img]http://img593.imageshack.us/img593/6013/glest3.png[/img]
Our reaper has legs!  Culling always hidden surfaces (on the assumption that things cannot be viewed from beneath; is there a way to infer this, or must the modder tell the tool?) will save quite a bit more RAM, and hopefully be much faster too.

743

Tools / Re: glest_mod_pack.py

« on: 11 December 2010, 06:46:27 »

Type:

 python glest_mod_pack.py

744

General discussion / Re: Rendering G3D using OpenGL

« on: 10 December 2010, 21:02:31 »

I had really understated the amount of trivial-to-find duplication of whole-meshes - a fix to my diff-code and quite a lot more pop up.  I seem to find all the wheels and things, which means that nice smooth rotations would be possible.

The new version of the tool renders the changing meshes in red (changing) and green (unchanging) parts, and shows that it seems fruitful to divide those meshes that do change into large unchanging parts and changing parts.

My thoughts for a new format would be:

• The model has a duration value.
• Each model has a vertex and normals array.  This is per-model, not per-frame.
• That each sub-model (using this term as its not a mesh) has an arbitrary number of frames, each frame has it's own time within the total model's duration.  Therefore, each sub-model does in a model does not need the same number of frames.
• Each frame in a sub-model is made up from an arbitrary number of operations.
• Each operations is a matrix and offsets and lengths into the model's vertex and normals array and the op-code to use - triangles, triangle strip, quads etc.

Existing G3D models would be converted to the new format by glest_mod_pack.py whilst packing the mod.  Changing the export tools for future models might be nice, but there seems plenty of scope for retro-repacking the old models.

And the code that draws this uses VBOs etc hopefully from the beginning.

745

General discussion / Re: Rendering G3D using OpenGL

« on: 10 December 2010, 17:18:04 »

Encouraging indeed

746

General discussion / Re: Rendering G3D using OpenGL

« on: 10 December 2010, 13:17:11 »

It's not possible to express a character animation with matrix transformations, e.g. walking. Too many parts of the mesh move differently.

That's quite true.  But there are many models with the opportunity to dramatically reduce the amount of data by sharing at the mesh level.  I've been writing some code to analyse them here:  https://github.com/williame/GlestTools

For example, take the nice catapult (which is perhaps more geometric-looking than normal):

I've differed each mesh each frame and in the table below all the ys are frames that are exact duplicates

Mesh4 8 228 432 y y y y y y y IMMUTABLE
Mesh4 8 393 1200 x x x x x x x mutable
Mesh4 8 9 24 y y y y y y y IMMUTABLE
Mesh4 8 86 264 y y y y y x y mutable
Mesh4 8 29 108 y x x x y x x mutable
Mesh4 8 67 216 y y y y y y y IMMUTABLE
Mesh4 8 116 168 x x x x x x x mutable
Mesh4 8 116 168 x x x x x x x mutable

The code to find duplication can only get cleverer.  It could be extended to detect scaling, and it could re-subdivide models to get optimal packing, and also detect mirroring and, importantly, hidden triangles.  All these changes save disk space, but importantly save RAM and can give the GPU less to render.  Big performance wins I think are worth chasing.

We'd need to add a version 5 of the G3D format to support any of this, of course.

My thought is its an optimisation step available in my glest_mod_pack.py tool.

747

General discussion / Re: Rendering G3D using OpenGL

« on: 9 December 2010, 13:45:11 »

Yes, I'm beginning to grasp the subtle tradeoffs between VBO, vertex arrays and display lists now.

I wrote a quick renderer in python so I could play about a bit:

Code: [Select]

[img]http://img20.imageshack.us/img20/5610/glest1.jpg[/img]
My initial thoughts were about level-of-detail - calculating simplified meshes to be used at further zooms - but I think to that you *can* often turn the current animation interpolation into single mesh lists with matrices.

I will play with both.

748

Tools / Re: glest_mod_pack.py

« on: 9 December 2010, 13:17:57 »

Yes, xz is a commandline tool with the same compression algorithm as 7zip.

Excellent that the packing now works!  Thank you for all your testing.

749

Off topic / Re: history's greatest disaster

« on: 9 December 2010, 11:01:36 »

An excellent book that will greatly inform and expand minds: https://secure.wikimedia.org/wikipedia/en/wiki/The_Second_World_War_%28book%29

750

General discussion / Re: Rendering G3D using OpenGL

« on: 9 December 2010, 09:56:16 »

On account of the above, VBOs for units is not going to work, all those frames of vertex data is far too much to be putting in video memory.

VBOs could well be worthwhile for for tileset objects, which aren't animated, and account for a fair proportion of the typical rendering time. Terrain and water rendering desperately needs to be converted to using VBOs and and using GLSL for the actual rendering, this will be happening in the near future. This has has been semi-discussed recently on the dev mailing list, sign up!

This interpolation approach seems very CPU and RAM intensive.

With display lists for the meshes and matrices for the frames, you'd use much less of both surely?