Cue introduction

Welcome back moopli! 

If you aren't already a developer, don't worry I'll add you now, because we need any coders we can get. Of course, give your first priorities to what work you have at university, but in any free time you can spare we would appreciate your help with the project. 

Crovea is currently doing the coding on GitHub, so make sure to contact him to get started. 

Also, we've made some progress since you were last here, so you might need to take some time to catch up to see where we are now in development.

Welcome back!

I haven't been running builds on Linux for a while now, but I don't imagine why any compatibility should have broken, so getting that running might be a place to get started! I deprecated the cross-compiling scripts (Linux->windows) as well, but we may want them working again for a build-server eventually.

Your work in soft-bodies could become very useful! This will hopefully work together with the microbe stages dynamic membrane that patowen has just started experimenting with: https://github.com/Revolutionary-Games/Thrive/issues/115

You can naturally take a look at the github issues and see if there is anything you are interested in working on. There should be a couple of easy-to-get-started with issues if you want.

If you have questions etc. just ask here, on github or hit me up on skype (below).

crovea wrote:

... but we may want them working again for a build-server eventually.

For a more permanent build server setup we could look to Travis. I wouldn't mind fiddling around with setting that up, as it would certainly be really useful.

Anyway I should get to building Thrive.

moopli wrote:

crovea wrote:

... but we may want them working again for a build-server eventually.

Fr a more permanent build server setup we could look to  Travis. I wouldn't mind fiddling around with setting that up, as it would certainly be really useful.

Anyway I should get to building Thrive.

Sorry, I'm a bit late to the party. But welcome! Its nice to see someone who can really help us.

Scottnov wrote:

Sorry, I'm a bit late to the party. But welcome!

Uh? Um. Thanks. Have I really been gone so long? Wow, you're a pretty prolific welcome wagon.

Anyway. It seems CEGUI can't find Ogre, at least from the linker errors I'm getting. Either that or version issues 'cuz 1) I'm still running Precise, and 2) CEGUI 0.8.3 might want Ogre 1.9.

moopli wrote:

Scottnov wrote:

Sorry, I'm a bit late to the party. But welcome!

Uh? Um. Thanks. Have I really been gone so long? Wow, you're a pretty prolific welcome wagon.

Anyway. It seems CEGUI can't find Ogre, at least from the linker errors I'm getting. Either that or version issues 'cuz 1)  I'm still running Precise, and 2) CEGUI 0.8.3 might want Ogre 1.9.

Oh, I was just saying welcome. More like re-welcome.

moopli wrote:

CEGUI 0.8.3 might want Ogre 1.9.

 

I'm certainly running ogre 1.8 (1.8.1 specifically) and CEGUI 0.8.3. I can try building on my mint VM to see if I get any issues, altough I probably will with my limited Linux exposure. If I succeed and you are still having issues, I can try on my 12.04 ubuntu server which should somewhat correlate to what I can gather that 'Precise' is.

How did you obtain CEGUI?

Scottnov wrote:

Oh, I was just saying welcome. More like re-welcome.

Heh yeah I was just confused by the apparent time warp.

Anyway, had a chat with crovea, CEGUI built successfully, but now I'm getting some cmake errors. So, progress, yay!

Cmake couldn't find a few boost libraries, so i installed libboost-all-dev, but now boost_chrono is still missing. CEGUI.h, Renderer.h, CEGUIBase-0_d and CEGUIOgreRenderer-0_d are also missing, so it seems it can't find CEGUI either.

Maybe the problem is that I'm running cmake without parameters (well, apart from . ), but not having much experience with cmake I can't be sure.

Quote :

but now boost_chrono is still missing

Try libboost-chrono-dev package

Quote :

so it seems it can't find CEGUI either

The findCEGUI.cmake script looks for CEGUI headers in the following places:

Code:

      ${CEGUI_ROOT}/include
      ${CEGUIDIR}/include
      ${CEGUIDIR}/cegui/include
      ~/Library/Frameworks
      /Library/Frameworks
      /usr/local/include
      /usr/include
      /sw/include # Fink
      /opt/local/include # DarwinPorts
      /opt/csw/include # Blastwave
      /opt/include
      /usr/freeware/include

And similarly for libraries. Do you have it in any of those places?

Okay now Boost is good, thanks. After I created a little precompilation script to set my environment variables, I was able to cut the issue down to missing CEGUIBase-0_d and CEGUIOgreRenderer-0_d. I'm pretty sure _d means debug, yes? So it seems I don't have a debug build of CEGUI. When I tried compiling Ogre in debug for CEGUI, i noticed boost wasn't getting linked in, and then some digging revealed that the version of my boost packages was 1.48. So now I'm rebuilding Boost. Yay.

One good thing comes out of this though -- I'm learning more and more about how to install libraries on linux, which'll be useful until the end of time. So. Bright side.

Edit: One faulty power bar later, the power to my computer cut out,cutting short the boost rebuild. I'll tackle this tomorrow. (gives you a chance to weigh in too -- again, there's a bright side)

Sounds like progress

Quote :

I'm pretty sure _d means debug

Yep!

So much for progress, turns out the PSU is shot.

But it shall return as soon as my computer is up and running again

Ah
Well I'll be here whenever you get things fixed up ^^

Now that other discussions are moving off of here and onto other threads, I'm gonna start using this as my personal soapbox (again).

So some more about me: As you might notice from my posts, I'm a bit of a cytology nerd. I'm also a bit of a space nerd, but slightly less so, and it isn't exactly gonna come in handy just yet

Anyway, I thought I'd use this place to store interesting technical things that might come in handy later in development.

So, at work yesterday I was reading some interesting papers and watching some cool videos. Here's one I remember that might come in handy later:


More to follow~

That skinning demo will be extremely useful (if we can get such a feature) for the organism editor, where skinning will be the final step to physically designing the player's organism, especially considering the fact that we will be having a wide variety of diverse organisms, and there could be lots of potential for incorrectly intersecting body parts and strange bulges with procedural animation.

Reading over the code, it occurs to me that this may come in handy for inspiration.

Some noteworthy bits:

• The command pattern will come in handy once we gear up for more advanced AI -- especially since we want to be able to assume control of organisms whenever we like.
  
• Flyweight might be useful once we're pushing hundreds of creatures to the GPU at a time -- though Ogre might handle instanced rendering, I'm not sure.
  
• Component is part of the Ogre way of doing things (or so I've heard :P), and I'm guessing we use it, but I'm not too sure how much.
  

If we've already discussed this sort of high-level architecture somewhere, does anyone have pointers to threads I can read?

Quote :

The command pattern

I'll have to read it thoroughly later, but it seems overly complicated for problems with seemingly trivial solutions. I'm not claiming that I know better than the author but I personally don't see the benefit in this specific pattern

Quote :

Flyweight

Sounds worthwhile to keep in mind, but I don't think its a good idea to mess with the rendering pipeline that ogre controls before we have a problem that we can't solve in other ways.

Quote :

Component

This is indeed what we are using, specifically the version called Artemis entity system framework. We use it for almost everything!

Quote :

does anyone have pointers to threads I can read?

We don't have a specialized architecture thread, but that might be a good idea!

crovea wrote:

I'll have to read it thoroughly later, but it seems overly complicated for problems with seemingly trivial solutions.

The trick is that the trivial solutions result in high coupling between commanders and commanded. As the link explains, the command pattern decouples the senders and receivers of orders. This decoupling is especially important for us, as we want to be able to plop the player in control of an organism that was until then taking its orders from something else. Until recently, actually, I didn't know this pattern had a name, and thought I'd independently invented it. From my experience, it's really useful.


Anyway, I was reading a paper at work today, and I thought it would be useful for fast, cheap microbe softness -- note though, that since we're storing position and orientation per-microbe, that there's no need to do the complicated shape-matching step; but just restitute each displaced point and apply corresponding forces to the center of the microbe.

crovea wrote:

We don't have a specialized architecture thread, but that might be a good idea!

As I have limited coding knowledge, this is a shot in the dark, but does this thread cover what you mean?

https://thrivegame.canadaboard.net/t1117-engine-architecture

Quote :

does this thread cover what you mean?

Yes it does Somehow forgot about it and missed it while looking for it

While I was at work I ran across some interesting papers. These won't be useful until much later, when we can afford to do interesting things with city development and infrastructure in Industrial Stage. Once we get there, however, I have big plans for making deep, beautiful cities.

And here's something cool talking about some state-of-the-art real-time raytracing, and hardware support that we could expect in a few years. If we ever need our own renderer that is

And here is a very comprehensive paper on position-based dynamics algorithms.

And another.

Changing it up a little, here we have a blog post detailing some great uses of github issues for project organization. Their tricks seem like they'll come in handy.


And here's a paper on the VDB, an amazingly-efficient datastructure for representing sparse volumetric data. It can store essentially infinitely large volumes, but the largest things I can see it being used for in Thrive are massive destructible asteroids and spaceships.

And here we have a good explanation of the Barnes-Hut algorithm, which could see lots of use in places like asteroid fields.

And then there's this book. It's pretty much the seminal book on the mathematics of plant structure, and should be a required read (for programmers at least) once we reach Organism Stage.

Here's a website that tracks libraries for API/ABI changes, listing backwards compatibility breaks. Very useful.

And changing it up a bunch, this thread is the home of a worldbuilding project, which, starting about 30 pages in, gets really detailed about placing tectonic plates, landforms, ocean currents, biomes, language groups, founder crops, civilization, and more.

In a few years we should probably sign up for GSoC. It'll be intense, certainly; but it would be a great step to take.

Here, some great stuff I've come across in a couple blogs today.

The GPU Gems series is full of great tidbits.

What every programmer should know about memory.

[url=http://nccastaff.bournemouth.ac.uk/jmacey/MastersProjects/MSc13/06/Jon Hudson Thesis.pdf]A pretty good paper on creature generation[/url].

Hofstede's cultural dimensions theory, a system for quantifying cultures along a bunch of different axes. Some parts will certainly need further generalization, but it's really eye-opening.

Someone must really remind me to reorganize this massive link mess.

OH look another link.