Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 3 4 [5]

Author Topic: GUM: Grand Unified Model—Weather shenanigans  (Read 5081 times)

Normandy

  • Bay Watcher
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #60 on: February 13, 2013, 08:19:28 pm »

@Skyrunner:
My git account is Maplenormandy.

@alway:
Sorry, I wasn't trying to be condescending or offensive, but I guess I could have come off like that. I just don't think we need to be so pessimistic. Careful, yes, but not so careful that we decide to forgo something like messaging that could really help in the long run.
Logged

Skyrunner

  • Bay Watcher
  • ?!?!
    • View Profile
    • Portfolio
Re: GUM: Grand Unified Model, Bay12 collab
« Reply #61 on: February 14, 2013, 09:46:56 am »

Edit2: first commit: https://github.com/warmist/GUM--Grand-Unified-Model/commit/3e0da4940d161af5d2aaf39aea5f24d4d25ab120
about c++11 i'm all for it :) using gcc4.7 here.
Can you tell me why const was added after some of the functions? o_O

Also... how to merge forks? xD


(Warning: little logical coherence ahead. Mostly random thoughts >.> Usually, a new line is an independent thought.)

Okay, I have made a reasonable mendel utility, and a module that makes use of the utility.

For starters, I have pushed a dirty copy of the project to github.
A few things that have been changed include a docs directory at the root, where each project has a folder with its doxygen documentation. I have also added a readme file which lists the requirements for each module.

Here, MendelianInheritance is a utility class, and MendelModule is a (ill-planned) module that uses MendelianInheritance. MendelModule has a few things that all modules should probably have, mainly a step() function specifying the unit of time it needs (generations). The reason MendelModule is ill-planned is because I wasn't able to provide any hooks for other modules to use. I also didn't write documentation yet.

Hopefully, I've provided a few guides as to what a module needs to have. To state it again, they're (1) a step() function (2) a readme with requirements, until something more permanent is created (3) a documentation file with doxygen, in html, added to the doc folder. It lives in a folder with the module name.

A module simulates something. This is the most important thing. =_= Interactivity can come when there are multiple modules. A module should preferably be thread-safe. As long as there is nothing to build off of, anything more specific than this will be difficult to say.

Assuming that we want to be able to simulate at least a small region, a few modules could be useful:
  • Terrain generator:
    Spoiler (click to show/hide)
  • Weather & climate generator:
    Spoiler (click to show/hide)
  • Some sort of creatures:
    Spoiler (click to show/hide)
  • Civilization?:
    Spoiler (click to show/hide)
I realized that the latter two need the first two to work. >.>

Is anyone up for an IRC meeting? o_O Multidirectional communication is probably more effective than the forum style.

Also, I wonder if people will be willing to contribute work they have done before, or if they'll write new models. xD
Logged

bay12 lower boards IRC:irc.darkmyst.org @ #bay12lb
"Oh, they never lie. They dissemble, evade, prevaricate, confoud, confuse, distract, obscure, subtly misrepresent and willfully misunderstand with what often appears to be a positively gleeful relish ... but they never lie" -- Look To Windward

Warmist

  • Bay Watcher
  • Master of unfinished jobs
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab—looking for IRC
« Reply #62 on: February 14, 2013, 10:54:30 am »

1) const after functions mean that they do not modify the object.
Code: [Select]
size_t stuff::getsize() const
{
 return mysize;
}
that means that you can use it like this:
Code: [Select]
void f(stuff const* a){
a->getsize(); //works, while without const would emit , that a const object is being modified.
}
2) to merge forks: pull from my repository into yours.
3) i might have something very similar to that terrain gen paper somewhere (those bastards copied my idea without me ever talking about that anywhere :D )
4) irc: i usually am at freenode (#dfhack)

more about const-correctness (this site is very good in general for c++/c++11 stuff, e.g. inheritance (including all the strange multiple/virtual cases), pointers (almost never use raw pointers in c++11), etc...)
« Last Edit: February 14, 2013, 11:13:17 am by Warmist »
Logged

alway

  • Bay Watcher
  • 🏳️‍⚧️
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab—looking for IRC
« Reply #63 on: February 14, 2013, 02:20:02 pm »

As for rendering, this weekend I can spend a few hours and get an easy to use setup for that done. Nothing fancy yet, but simple object rendering and 3d heightmap visualization should be pretty easy to implement. I'll be doing it in Win32 + DirectX11, since that's what I'm most familiar with and will take me the least time. When I get more free time, I'll see about putting together some Xlib and OpenGL rendering, hopefully with precisely the same interface.

On a related note: Platform dependencies. A variety of things will be platform dependent, be they CUDA, Win32, or DirectX. As such, I recommend we have some header file with things like #define WINDOWS_BUILD, #define LINUX_BUILD, #define CUDA_BUILD, which can then be used by any platform dependent parts with #ifdef to toggle which parts we want to be used. Then we should theoretically be able to simply comment out a single define line to disable/swap out all the incompatible modules.

Edit: okay, it's going to be a few more days; finals week and all that. >_<
« Last Edit: February 18, 2013, 05:00:03 pm by alway »
Logged

Mego

  • Bay Watcher
  • [PREFSTRING:MADNESS]
    • View Profile
Re: GUM: Grand Unified Model, Bay12 collab—looking for IRC
« Reply #64 on: February 19, 2013, 03:26:10 am »

I'd be interested to see what could come out of this. And, if I can, I'll toss some code in, too.

Skyrunner

  • Bay Watcher
  • ?!?!
    • View Profile
    • Portfolio
Re: GUM: Grand Unified Model, Bay12 collab—looking for IRC
« Reply #65 on: February 19, 2013, 03:30:04 am »

Current problem is creating any momentum at all >_<
Logged

bay12 lower boards IRC:irc.darkmyst.org @ #bay12lb
"Oh, they never lie. They dissemble, evade, prevaricate, confoud, confuse, distract, obscure, subtly misrepresent and willfully misunderstand with what often appears to be a positively gleeful relish ... but they never lie" -- Look To Windward

Skyrunner

  • Bay Watcher
  • ?!?!
    • View Profile
    • Portfolio
Re: GUM: Grand Unified Model, Bay12 collab—looking for IRC
« Reply #66 on: April 18, 2013, 09:59:32 am »

An update.



While I've got nothing pushed to the repo, I've been slowly doing work on the weather generator. And by slowly, I mean "started working on it one week ago after all this while" >_>

The numbers printed to the console tell you nothing about the story, so here's a set of more informative charts to view.

Spoiler: January temp (click to show/hide)
Spoiler: June temp (click to show/hide)
Spoiler:  June temp, problem (click to show/hide)
The problem in the above graph is that sometimes the min temp and the max temp are really really close to each other. Not quite sure how to fix it...

Spoiler: September (click to show/hide)
The trend is downwards as you enter winter.


Edit: The rain+temp says that rainfall and temperature is concentrated towards summer, which is exactly whatthe climate for that test data is like (South Korea there). The weather isn't smooth, with there being heat spikes occassionaly that aren't uniformly random. The rain itself is a Markov-chain with two states (rain, no rain).
To generate different weather, you just need to swap the various data files (.rain, .sun, .temphi, .templo) to the climate you want. Or, if you have no real-world anaology for the weather you want, uou can make up data files via RNGs to simulate weather of your choosing.
If anyone's interested, I can push the sim to the repo along with the data files.

The sim itself works using step(<no. of days to advance the state by>). . Weather stats are accessed by getter methods to prevent any external functions from modifying the info. It keeps track of the date and month using a Month class. All data is input by using rain parser objects that read from specifically formatted plaintext data files.

I also wanted to post a screenshot of Alway's renderer and my flow simulator, but I ran out of PC time. Link's in my sig, though, so check it out if you're curious. O.o

Currently this collab is more like a one-person-project, mind you. X3
« Last Edit: April 18, 2013, 10:11:43 am by Skyrunner »
Logged

bay12 lower boards IRC:irc.darkmyst.org @ #bay12lb
"Oh, they never lie. They dissemble, evade, prevaricate, confoud, confuse, distract, obscure, subtly misrepresent and willfully misunderstand with what often appears to be a positively gleeful relish ... but they never lie" -- Look To Windward

Anvilfolk

  • Bay Watcher
  • Love! <3
    • View Profile
    • Portuguese blacksmithing forum!
Re: GUM: Grand Unified Model, Bay12 collab—looking for IRC
« Reply #67 on: April 18, 2013, 10:12:09 am »

Nice! Still looking forward to seeing what comes out of this!

What's the interface for accessing this?

Skyrunner

  • Bay Watcher
  • ?!?!
    • View Profile
    • Portfolio
Re: GUM: Grand Unified Model, Bay12 collab—looking for IRC
« Reply #68 on: April 18, 2013, 10:15:59 am »

I edited the post above, but here's something more specific.

void step(int daysToAdvance) Advances the state by the argument number of days. Default 1.
float/int getMinTemp/MaxTemp/Rain/Date/Month/Radiation() Getters. Month is 1~12.
void changeDate(int month, int day) Pretty obvious. It doesn't do anything if the supplied arguments are invalid. What it does can be defined in the Month class it uses to track the date. I skipped error-checking because lazy >_> <_<

That's pretty much it.

Oh, you do have to insert data with three or four functions. ><


Edit: I forgot to mention that I didn't implement average humidity, wind speed, and wind direction yet. The reason is simple. I actually wrote all the functions for humidity in Excel, but the generated stats are nearly identical to the original data. Probably because the standard deviation of humidity within a month is really low... Implementin it when/if I need it.

Next up is the dreaded hydrology. :S
« Last Edit: April 18, 2013, 11:03:38 am by Skyrunner »
Logged

bay12 lower boards IRC:irc.darkmyst.org @ #bay12lb
"Oh, they never lie. They dissemble, evade, prevaricate, confoud, confuse, distract, obscure, subtly misrepresent and willfully misunderstand with what often appears to be a positively gleeful relish ... but they never lie" -- Look To Windward

Gamerlord

  • Bay Watcher
  • Novice GM
    • View Profile
Re: GUM: Grand Unified Model—Weather shenanigans
« Reply #69 on: April 18, 2013, 10:54:32 am »

Yay! This thing ain't dead!
Pages: 1 ... 3 4 [5]