Messages

51

Tools / Re: Optimising G3D tool

« on: 19 June 2013, 13:10:46 »

hi titi,

this tool is not doing any removal of anything.  All it does it join together meshes that share the same textures and have the same number of frames.

So when drawing the Mr War's trees, which he made by lots of copy-n-paste-n-move of a mesh in blender, is now done with one draw call instead of 5 (or whatever).

The export scripts in blender could do the same optimisation, or the optimisation could be done automatically on load by MG.

52

Tools / Re: Optimising G3D tool

« on: 25 April 2013, 16:52:54 »

I still use G3Ds for hobby projects, mostly targeting webGL.

I had a landscape with 1000s of G3D trees on.  And it went quite slowly.

I run this g3dopt.py script on them - https://raw.github.com/williame/barebones.js/gh-pages/g3dopt.py - and the scene drew really fast afterwards!

I was stunned that the tool could have such an impact!

The extent to which various factors played a part: that it was webGL+Angle, that it was on low-powered laptops, that the models of trees Mr War gave me were exceedingly unoptimal - all these factors can be ignored!

It'll never hurt to run all your G3Ds through this tool and then Silnarm's excellent G3DHack optimiser!  And someone with a low-end graphics card might thank you for the thought!

Hope this helps,

Will.

53

Feature requests / Re: Suggestion: conquer enemy's building instead of burning them down

« on: 12 April 2013, 06:04:02 »

I think there are technical challenges, balance concerns and AI complexity.  We have to talk about these three aspects separately.

Balance: We take long enough to balance the standard fractions we have already without capture in the equation.

Technical: But if the technical facility can be added cleanly to the engine, then letting new techtrees use it would be cool.

AI: well this is the biggest technical challenge, eh?

I imagine it working like a new attribute - rather than hp, some kind of 'influence' that gets increased by a special attack.

54

Feature requests / Re: Suggestion: conquer enemy's building instead of burning them down

« on: 11 April 2013, 05:55:00 »

Capturing buildings and brain-washing units would be a very interesting new game dynamic for modders to enable.

It goes all the way back to Dune 2.

55

Off topic / Re: Planetary Annihilation development video

« on: 5 April 2013, 07:21:04 »

Thank you for posting the link

56

General discussion / Re: webgl

« on: 28 January 2013, 10:16:20 »

I have never used it nor know how it works, but three.js is the standard go-to library for loading models and drawing things in webgl.

57

MegaGlest / Re: Graphics Improvements Discussion

« on: 9 January 2013, 06:51:09 »

(In order to discuss model formats you really need to start by discussing use-cases.

Do you want humanoid movement?

Do you want turning turrets and such?

How will these work?

Then you can go looking for a format that better suits the use-case)

58

General discussion / Re: Please read: Is the Glest Advanced Engine project dead?

« on: 21 December 2012, 07:26:15 »

I had no trouble getting the commit bit on GAE and features I coded for MG into MG either.  I mean, there's no hurdle to contributing to either or both projects, and MG has never - in my actual experience - been anti-feature.

I had no trouble getting code in to support Mr War's mods even though sci-fi is miles from MG's "story line".

What I think people misinterpret is that MG want you to explain how your feature is complete and water-tight before it gets committed, which we can thank them for.  If you add water buildings, they'll want to know what the AI does with them...

As an observation GAE was more open to untested incomplete submissions, which is totally cool and totally what they were about facilitating.

But we can talk about big plans and mull why MG isn't cool enough to be mainstream, but it really bugs me how the less you can yourself create the more dismissive you are of the excellent, painstaking, never-ending work people like Softcoder and Silnarm and co have put in.

59

Off topic / Re: Ludum Dare

« on: 8 December 2012, 10:36:12 »

[big]Ludum Dare 25[/big] is next weekend!  http://www.ludumdare.com/compo/ [big]December 14th-17th, 2012[/big]

Of course a glest community team will be entering!  If you want to make a game with us, even if you cannot find a whole weekend of free time, you are most welcome!  And if you can be a play-tester for us, you are most welcome too!!

If you can think of any general game ideas, please list them here too!  Its great to have a few well-thought-out and varied game-ideas to work with when we hear what the theme is.

And, if you are near a "real world gathering" http://www.ludumdare.com/compo/2012/11/13/real-world-ludum-dare-25-gatherings/ next weekend, you would love to contact the organisers so you can look in on them, or sit in there - even for just a short while - while you play-test or code with the glest community team!

60

General discussion / Re: Looking for 3D molleders [Paid work]

« on: 16 November 2012, 08:22:19 »

As someone who dreams of being an indie game developer, and as someone who pays close attention to the startup scene and so on, please permit a meta-question:

How is your business set up?  How are you funding it?  Basically, everything about your whole project from a business aspect; we'd all be super interested to know how you go about the actual business side of things, as it might inspire and inform us in our own endeavours at a later date

61

General discussion / Re: Please read: Is the Glest Advanced Engine project dead?

« on: 8 November 2012, 07:52:36 »

I think this would be a good idea.

Make the top-level categories MG-specific and then put the classic Glest and the GAE boards under child boards

Something like:

Installation and getting started (MG-specific, but you don't need to say that in the title)
General Discussion (MG-specific, but you don't need to say that in the title)
Modding (again MG-specific, without child boards for maps and variations; just put it all in one big bucket; Tools in here too)
(the Glest Advanced Engine fork) (put everything about GAE under here, and put the board name in brackets so its subtly clear its inactive)
(archived forum) (includes all the old Glest boards)

Having too many boards at the top-level, and having too many boards in general, is not making it easier for new people to know where they go to interact with livies

62

MegaGlest / Re: cegui

« on: 3 November 2012, 11:48:29 »

Cygal +1

63

MegaGlest / Re: Frame-lock-networking amongst others.

« on: 17 October 2012, 09:58:19 »

I'm sure there was a *better* write-up of how Valve does prediction/correction, but this is the doc I found by Googling https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

The whole of their SDK docs is worth reading.

64

Feature requests / Re: quality settings

« on: 10 October 2012, 09:37:27 »

The megapack - those models I've looked at - seem to be very reasonable complexity.

Mr War's models tend to be on the simple side, although even his models get dramatically reduced by G3dHack and my own optimisers.

Lots of other random models I've sampled though are way over-complex.

And then we add first-person-camera and suddenly the definition of 'acceptable' might change.

Generally, the way forward I think is adopting a bone format, and auto-simplification-in-code, and then artists can produce high-res models that are acceptable sizes and everyone is happy.

Lots of code to be written, though.

65

Tools / Re: GlestTools (on github)

« on: 2 October 2012, 05:49:00 »

Hi RV_007

what happens at the Windows command prompt when you type the command 'python'?

Can you paste the output here so I can see it?

thx
Will

66

Feature requests / Re: quality settings

« on: 1 October 2012, 08:27:46 »

+1 what Omega said

for textures, another good tweak is anisotropic filtering.

but absolutely have it on a nice single slider, perhaps with an 'advanced' settings page for others.

67

Feature requests / Re: quality settings

« on: 1 October 2012, 06:52:09 »

I would prefer the engine to do the mesh simplification, and for distant models to avoid interpolation and so on.  All best done in the engine, rather than in the artwork.

68

Tools / Re: G3dHack - alpha9

« on: 21 September 2012, 21:59:57 »

Hey that was pretty neat Yggdrasil.

For a long time I imagined making such a tool - a structured hex editor which understood structures, and a similar libstructure thing that would be equally useful for better-compressing files too.

All programmers dream of making tools I guess.

69

General discussion / Re: Optimizing g3d files

« on: 17 September 2012, 09:44:08 »

Yeah as softcoder said, IQM is like MD5 but with better exporters from blender and unquestionable license.

So IQM all the way, I say!

The key thing is a move from keyframe to bone animation.

It is however preferable that the loader differentiates between single frame still meshes and multi-frame ones, and bakes-in the actual vertex positions.  Bones are not free runtime-wise in GPUs.

70

General discussion / Re: Optimizing g3d files

« on: 17 September 2012, 05:34:19 »

I use the G3D format in my own hobby projects, including webGL.

In webGL scenarios, I've found merging meshes with the same number of frames is a big win; its about reducing the draw calls, rather than the vertices.  In browsers e.g. javascript and NaCL it can add a few FPS!  I speculate that it can help even mainstream OpenGL, and I it will never hurt.  It also gives G3dHack a second chance to optimise the model into fewer vertices.

There's the whole general area of simplifying meshes that is not really being explored, too.

I made a simple tool.  I found using it as a preprocessor with G3dHack gave the best returns.

https://forum.megaglest.org/index.php?topic=8560.0

Regards model formats, I think MD5 would be the biggest win.

I've thought about how to super-compress models before - http://williamedwardscoder.tumblr.com/post/17369540725/compressing-3d-game-models - but my current preference is just go for a text format and let a text compressor compress them!  MD5.  Bones not frames.

71

Tools / Re: G3dHack - alpha9

« on: 15 September 2012, 18:53:13 »

I had checked manually in a hex editor.

Mr War confirmed that he hadn't done the normals after using some extrude tool or something in Blender.  He generated corrected G3Ds.

But, in the meantime, I did make a nice flat-shading auto-normals tool.  Now I'm exploring how to do mesh-based collisions.

72

Tools / Re: G3dHack - alpha9

« on: 9 September 2012, 20:47:17 »

How does g3dhack handle - and show - normals if the G3D has 0,0,0 as the normal?

I ask as I think some of the models that Mr War is giving me have ... 0,0,0 as normals on some vertices.

I've double triple checked my code and I really think there are whole sections of the G3Ds coming out of Blender that 0-magnitude normals.

Yet g3dhack shows them (going exactly 1z).

Also, any chance of an auto-normals tool?  Do such things exist?  How can we get Mr War to actually use normals properly in the first place?

73

Off topic / Re: Ludum Dare

« on: 9 September 2012, 20:43:43 »

hmm sounds like network problems your end e.g. routing/firewall/etc, Eliminator

74

Off topic / Re: Ludum Dare

« on: 7 September 2012, 15:19:11 »

@Ishmaru

yes I agree with you.  I've just done proper hit-testing and its surprising me how fast it is.  Perfectly useable.

However, I can't change the submitted game like that.

the *next* game will obviously be slicker.  I think the next game is in February or so.

@ElimiNator

are you using chrome or firefox?  Does it show a splash screen?  Deos it say its connecting?  Does it say you have a problem with your webGL?  Are you using Linux or Windows?

75

Off topic / Re: Ludum Dare

« on: 2 September 2012, 06:14:47 »

yes the hits on the models is approximated by spheres.  Sphere/ray intersection is simple and fast.  Each ship is a little sphere, and its the same size regardless of model.  All models are much the same size but there is variation, and none are spherical.  This means a head-on shot might look like it misses the model but actually there's a whole sphere of vulnerability.

Additionally, I picked the number at random and calibrated it by openning two browser windows and firing at ships from point blank range.  I could easily have set it too generous.

This is the (C++, but still) code for sphere/ray intersection; the only intersection simpler is sphere/sphere:
https://github.com/williame/GlestNG/blob/master/3d.cpp#L271

And here's the code for a triangle:
https://github.com/williame/GlestNG/blob/master/3d.cpp#L393

There's a lot more ops like dot-product in the triangle code and its just massively slower.  Additionally you have to test every triangle (until hit) in the model, and there are at least a few hundred of them.

The normal way you'd do things is to do sphere-sphere intersection of the ray/sphere, then if it hits its ray/sphere intersection properly, and then if that hits you check the individual triangles.  There are actually people who use simplified mesh hierarchies and spatial indices before checking the full mesh too.

I say all this because I find it an interesting subject.

It would be interesting to imagine what this game *could* be, with some polish...