Log for #openttdcoop.devzone on 24th May 2012:
Times are UTC Toggle Colours
01:10:37  <Brot6> OpenGFX+ Trains - Revision 559:e2b2c9a56b49: Add: Render run of passenger, mail and armoured wagons (Xotic750) @
01:11:11  <Brot6> OpenGFX+ Trains - Revision 560:7d96ee58dd12: Add: Post-processed run of passenger, mail and armoured... (Xotic750) @
02:06:19  *** KenjiE20 has quit IRC
02:06:47  *** KenjiE20 has joined #openttdcoop.devzone
04:19:46  *** Nat_aS is now known as Nat_AFK
04:26:48  *** Nat_AFK is now known as Nat_aS
04:32:58  *** andythenorth has joined #openttdcoop.devzone
04:48:34  *** Zuu has joined #openttdcoop.devzone
05:36:44  *** andythenorth has quit IRC
05:45:27  *** andythenorth has joined #openttdcoop.devzone
06:15:24  *** andythenorth has left #openttdcoop.devzone
07:52:45  *** orudge` is now known as orudge
08:03:23  *** KenjiE20 has quit IRC
08:07:26  *** Nat_aS is now known as Nat_AFK
09:35:18  *** frosch123 has joined #openttdcoop.devzone
09:56:27  <Xotic750> planetmaker: render finished and we were both wrong,
09:57:03  <planetmaker> @calc 1017 / 60
09:57:03  <Webster> planetmaker: 16.95
09:57:12  <planetmaker> 16 hours for...?
09:57:40  <planetmaker> all vehicles? One vehicle?
09:58:59  <Xotic750> that was all vehicles at the time, but now we have nearly twice the numver of models :)
09:59:23  <Xotic750> and that was just the render stage
10:15:43  <planetmaker> so... much faster?
10:17:38  <Xotic750> it rook 2 days using my 3 old laptops in a render farm, so yeah, twice as fast :)
10:17:59  <Xotic750> 17 hours is a definate improvement
10:19:51  <Xotic750> and I was able to do modelling while the server renders :)
10:21:49  <Ammler> and how much was our system busy?
10:22:04  <Ammler> (I assigned 1 cpu only)
10:24:35  <Ammler> <-- is that the time of your render?
10:25:15  *** KenjiE20 has joined #openttdcoop.devzone
10:25:48  <Xotic750> no, because munin only started hours into it
10:26:07  <Xotic750> this was actual time
10:26:40  <Xotic750> which was 17 hours, but now I have doubled the number of models
10:26:41  <Ammler> yes, that is what the munin time tells
10:26:54  <Xotic750> oh, ok
10:27:23  <Ammler> 1 cpu was around 16 hours occupied
10:27:54  <Xotic750> yep, now I have doubled the number of models
10:28:02  <Ammler> if it didn't hurt the system, we could assign a 2nd cpu
10:28:35  <Xotic750> I'm going to do the post processing run later today to see how that goes
10:29:14  <Xotic750> once I finish a few things and upload them, that will actually be a useful run too
10:29:26  <Xotic750> that I can push to the repo
10:29:37  <Xotic750> I expect a similar time
10:29:55  <Ammler> so with 2 cpus, it would half the time?
10:30:22  <Xotic750> blender certainly uses as many processor as you throw at it
10:30:32  <Xotic750> I think gimp does too
10:30:46  <Xotic750> but the post-processing uses alot of disk activity
10:30:54  <Xotic750> so that slows things down
10:31:13  <Xotic750> and usually post-processing uses about 50% of my cycles due to disk activity
10:31:42  <Xotic750> blender is where the cycles are really felt
10:33:15  <Ammler> well, we will see, I rised cpu limit to 2
10:34:05  <Xotic750> I will probably start post processing in about 1 hour from now
10:37:18  <Ammler> if that overall does not hurt, we might also rise cpu limit to 4, then theoretically the render should be done over night :-)
10:39:26  <Xotic750> :)
10:39:41  <V453000> big numbers :) By the way, have you considered making ogfx+ trains also work like CETS in the curves? Like it has about 24 view instead of 8 ... I guess that would be just adding an extra render command when you already have the models
10:39:46  <V453000> also hi :p
10:40:35  <Xotic750> my estimate at the moment, is that the repo will be in the region of 4GB when all is done, we are current around 1GB
10:40:58  <Xotic750> to goto 24 views you can increase that size by 3 :)
10:41:18  <V453000> hm I guess the newgrf will be big in the end eh
10:41:24  <Xotic750> same with rendering time, but the actual work to achieve it is very small
10:41:34  <V453000> yeah
10:41:38  <Xotic750> I mean the blender work
10:42:00  <Xotic750> I can just change the animation angle in the library and the number of frames to render
10:42:06  <Xotic750> and bingo, 24 views
10:42:26  <V453000> I dont know, just a suggestion ... I wouldnt eve draw that many sprites by hand, but rendering them sounds reasonable ... I guess the size is a pain tho
10:43:04  <Xotic750> well I guess 14 -16GB of repo might cause a stir :P
10:43:15  <V453000> hmm
10:44:11  <Xotic750> and base on a linear increase, the grf is aroun 15MB just now, it's going to be about 60MB when finished
10:44:30  <V453000> 200mb grf? :D
10:44:33  <Xotic750> multiply that by 3 and we have 180MB grf
10:44:36  <Xotic750> yep
10:45:17  <Xotic750> should be a good test of the coding :)
10:45:25  <V453000> hm :)
10:45:44  <V453000> well I didnt think of that size downside :) the 12 view feature is a bit useless then
10:46:17  <Xotic750> 12 isn't a huge increase from 8, but 24 is
10:46:31  <V453000> how many are there? 24?
10:46:33  <V453000> not sure
10:47:40  <V453000> yeah 24
10:48:15  <V453000> a bit strange, drawing that is suicide and rendering it is too big :(
10:48:58  <Xotic750> I wouldn't want to draw all those by hand
10:50:02  <Xotic750> so long as computing carries on as it does, 24 rendered will not be such a big issue in say a couple of years :)
10:50:04  <V453000> well some people do :d though I am not sure how much is drawn for CETS
10:50:14  <V453000> yeah I guess
10:50:33  <V453000> honestly, I myself wouldnt have a problem with that big newgrf, but I guess some people would
10:50:50  <Xotic750> yep, I'm sure :)
10:51:05  <Ammler> does ogfx-trains also have the default train sprites?
10:51:08  <Xotic750> and think of it on mobile devices :P
10:51:13  <V453000> lol
10:51:31  <Xotic750> yes, it has the default 8bpp sprites
10:51:34  <V453000> completely forgot about mobile things
10:52:03  <Xotic750> and I have mostly developed 8bpp from my renders too
10:52:16  <Xotic750> so we can use either
10:52:27  <Ammler> Xotic750: no, I mean ogfx-trains was just an extension to the baseset, with your 32bpp sprites, do you also render sprites for the baseset sprites?
10:52:30  <Xotic750> original 8bpp, rendered 8bpp or 32bpp
10:52:49  <Xotic750> yes, plus a few more
10:53:04  <Xotic750> so they can be reused
10:53:28  <Ammler> and you have done around 25% now?
10:53:56  <V453000> well if you think about it, people who have problems with space or are on a mobile device probably arent going to use 32bpp/ez things
10:54:16  <Xotic750> about 25% of ogfx I would guess, depends on how much extra animation we do, for example like loading passenger wagons with doors open
10:54:18  <Xotic750> etc etc
10:54:28  <Ammler> well, the question is, if there is need for 2 versions, like a light version without 32bpp
10:54:29  <Xotic750> if we don't do all that then about 50% now
10:55:09  <Xotic750> my guess would be 2 version is good :)
10:55:25  <Ammler> ogfx-trains doesn't do that now, right?
10:55:29  <Xotic750> nope
10:55:44  <V453000> I think one version would be great as people with ogfx+ trains could join any server - with ligh or heavy version, and at the same time they could have only one of them - no need to download the eventual 60/180 MB
10:55:56  <V453000> but that would need some option to choose that
10:56:04  <Ammler> no
10:56:10  <V453000> which I guess is above the scope of newgrfs
10:56:13  <Ammler> the 32bpp addon is "static"
10:56:43  <Ammler> or what you mean with option?
10:56:56  <V453000> that for example, I would want to join a server with opengfx+ trains
10:57:04  <V453000> but I only have the light version
10:57:05  <Xotic750> at the moment, ogfx trains is going to be pretty limited to desktop/laptop machines
10:57:28  <V453000> and still some people on the server want to use the big version
10:57:31  <Ammler> that should not hurt, as said, the 32bpp addon should only be static
10:57:44  <V453000> so it could run like something like that?
10:57:57  <V453000> one newgrf on the server, and the client would decide what to do with it?
10:58:01  <Ammler> yes, like you use different basesets
10:58:07  <V453000> I see
10:58:09  <Ammler> you can also use different static newgrfs
10:58:38  <V453000> well, then even 180MB wouldnt hurt imo Xotic750 :) people who cant get that simply use the light version
10:58:44  <Ammler> the 32bpp has no additional "logic"
10:59:06  <Ammler> that wouldn't work, afaik :-)
10:59:13  <Xotic750> that can be done, but first, need the models :)
10:59:19  <Ammler> the cets version is different logic :-)
10:59:56  <Xotic750> once I have models I can do 360 views :P
11:00:06  <V453000> :p
11:00:12  <V453000> cets logic is make 19380000 sprites, have fun?
11:00:18  <Xotic750> smooth :D :D
11:01:16  <Ammler> but you could make a cets version and "lighten" it
11:01:55  <V453000> the ez sprites are the most memory hog I guess
11:01:58  <V453000> 32bpp too?
11:02:13  <Ammler> IMO, CETS view should be supported by openttd (grfv9 maybe) instead with the "ugly" hack
11:02:19  <V453000> I mean, how much larger does a 32bpp png have to be in compare to 8bpp
11:03:13  <V453000> well I dont really know how it works, the hack looks quite nice. But the only issue I could see is people doing 3x the amount of pixel work
11:03:29  <V453000> if the views are rendered it sure is worth it
11:03:34  <V453000> but drawing it?
11:03:42  <Xotic750> 1x view is about 1.1k
11:03:53  <Ammler> Xotic750: do you also render the 8bpp part?
11:04:00  <V453000> and with the amount of trains that CETS plans, I would be a bit nervous about it getting completed
11:04:02  <Xotic750> 2x view is 2.4k
11:04:15  <Xotic750> 4x view is 6.9k
11:04:41  <Xotic750> I render in 32bpp, but have a process that can convert it to 8bpp, that's done in posty processing
11:05:17  <Xotic750> it's not possible to render direct in 8bpp
11:05:28  <Xotic750> or even convert to 8bpp in blender
11:05:49  <Xotic750> that has to be done by gimp, or imagemagic or photoshop etc etc
11:05:53  <Ammler> hmm, why do you add the rendered sprites to the repo instead extend the build process and add blender there?
11:06:22  <Ammler> wouldn't that solve the "big-source-repo" issue?
11:06:34  <Xotic750> because it has been taking me 4 days to render and process
11:06:46  <Xotic750> without some kind of render farm
11:07:04  <Xotic750> it's a case of time vs size
11:07:09  <Xotic750> and which is the cheaper
11:08:05  <Ammler> I would at least split the repo to "pure-source" and "source-with-render" (as subrepo)
11:08:29  <Xotic750> well, planetmaker has been working on the largefiles thing in hg
11:08:36  <Xotic750> which should pretty much do that
11:08:39  <Ammler> this is no largefile issue
11:08:49  <Ammler> the files aren't large, those are many
11:10:22  <Xotic750> I have suggested it but pm seems to think that breaks some of the ideas or something with hg
11:10:31  <Xotic750> that was how I was doing it in git
11:10:41  <Xotic750> I have a main with sub-repos
11:11:02  <Xotic750> and they only get loaded if you recurse the pull
11:11:13  <Ammler> it sounds well and should be supported by the devzone cf without change
11:12:07  <Xotic750> for me, bandwidth is not a problem, even 4GB of source is no real issue
11:12:19  <Xotic750> the big thing is getting a pull over http
11:12:23  <Ammler> the issue is not the size
11:12:24  <Xotic750> hence time
11:12:38  <Ammler> the issue is that you download a lot you probably want to build self
11:13:35  <Ammler> of course, I need to fix this issue anyway ;-)
11:13:55  <Xotic750> I don't thin even most people would want to build the sprites from the raw images, the post-processing part
11:14:15  <Xotic750> and very very few will ever want to build from scratch
11:14:23  <Ammler> well, it just means run make
11:15:10  <Xotic750> and for me that would mean a 4 day wait for the grf to pop out the other end :)
11:15:26  <Ammler> :-d
11:15:28  <Ammler> :-D
11:15:50  <Ammler> in that case, you have the "optional" subrepo
11:16:43  <Xotic750> a cunning way would be to compress and use the compressed file like a filesystem
11:17:02  <Xotic750> compressing the whole directory into xz makes it pretty small
11:17:21  <Xotic750> but I have no idea how to use an xz file like a filesystem
11:18:00  <Ammler> not sure, I get why this is "cunning"
11:18:44  <Xotic750> ok, just drop the cunning from the sentence :)
11:19:16  <Ammler> if compressing the rendered images makes it smaller, you probably do something wrong, don't you?
11:21:59  <Xotic750> but for example all the blend file compress down to about 25% of original
11:22:17  <Xotic750> I haven't tried all the .png
11:22:33  <Xotic750> the png are being png compressed at 90%
11:23:37  <Xotic750> infact even better, the main library (30MB) compressed to about 4MB
11:24:49  <Xotic750> even if the png do not compress much, there is still a saving, hdd block size and a few other things
11:26:22  <Ammler> Xotic750: the vcs does also compress, so this is useless
11:26:36  <Ammler> and I see no use to compress workspace
11:27:11  <Xotic750> just floating other possible untested ideas
11:28:08  <Xotic750> whatever is decided, I'm sure that other 32bpp projects that come along will be bigger and gain from our experience and decisions
11:29:44  <Xotic750> now I'm going to make the repor bigger :)
11:32:21  <planetmaker> V453000: it's entirely possible now to strip ogfx+trains of the 32bpp or zoom levels and OpenTTD will consider the newGRFs the same
11:32:45  <planetmaker> thus the "basic" and the "full" version are compatible and can be used concurrently in MP
11:32:46  <V453000> :)
11:32:51  <V453000> nice
11:34:11  <planetmaker> it's actually envisioned to allow bananas to do that... and that authors then only upload the full version
11:34:30  <V453000> oh, interesting
11:34:38  <V453000> I will stay with the light :p
11:35:43  <Brot6> OpenGFX+ Trains - Revision 561:adac85d9d382: Add: Render run of all monorail flatbed wagons (Xotic750) @
11:35:43  <Brot6> OpenGFX+ Trains - Revision 562:ff45b5753ea1: Add: Render run of all monorail flatbed wagons (Xotic750) @
11:39:28  <Ammler> planetmaker: you might have missed it, gave render another cpu
11:39:41  <planetmaker> I saw that. I fully agree
11:39:52  <Xotic750> now, I'm going to do the post-process run on the server
11:40:58  <Xotic750> and we're off :)
11:47:58  <Xotic750> after this run the repo is going to hit the 1GB mark :)
11:50:04  <Xotic750> lots of new sprites to be added to the nml btw, if you have any time planetmaker :)
14:42:55  <Brot6> OpenGFX+ Trains - Revision 563:c8c504fd33e7: Fix: Incorrect output directory (Xotic750) @
15:46:11  <Brot6> OpenGFX+ Trains - Revision 564:0109cc2b45b2: Add: Render run of monorail tank wagons + 1/2 the post-... (Xotic750) @
16:00:05  *** Nat_AFK is now known as Nat_aS
16:11:09  <Brot6> OpenGFX+ Trains - Revision 565:684979310d09: Change: Aligned some whitespace (Xotic750) @
16:12:50  <Brot6> OpenGFX+ Trains - Revision 566:f6e9f7c76071: Add: 8 sprite loading template for wagons and vehicles ... (Xotic750) @
16:14:29  <Brot6> OpenGFX+ Trains - Revision 567:954913459501: Add: Prepared nml for future open door loading sprites (Xotic750) @
16:16:11  <Brot6> OpenGFX+ Trains - Revision 568:d92c43d97e7a: Feature: Make use of 32bpp sprites (Xotic750) @
16:17:58  *** ODM has joined #openttdcoop.devzone
16:26:13  <Xotic750> Any idea when the next nightly build will be?
16:39:55  <planetmaker> No idea. But it should be built... nightly. Looking at it now
16:46:27  <Xotic750> If it gets built then I will make an announcement in the dev thread about the new monorail sprites :)
16:46:55  <Xotic750> The bulk and flatbed monorail sprites still need coding though, and I off for a few days now
16:50:41  <Xotic750> but if I get to borrow a PC when away then I may get a chance to look at the nml (hangover permitting) :P
16:56:52  <Xotic750> I will upload the rest of the post-processing run once it finishes (provided it doesn't break for any reason again)
17:12:30  <planetmaker> ok. Currently I can't manually start it as the nightly build of stuff still runs
17:17:12  <Xotic750> strage that the last build was 14/5
17:18:31  <Ammler> planetmaker: why do you think, there is nightly running right now?
17:20:04  <Ammler> I would rather think, nightly build is stalled since 16.
17:20:30  <Ammler> hmm, strange
17:21:36  <planetmaker> Ammler: both queues, nightly and release were kinda stuck
17:21:40  <planetmaker> I cleaned them
17:21:44  <planetmaker> there was nothing built for days
17:24:57  <Xotic750> btw, 2nd processor made a huge difference with rendering speed ;)
17:25:11  <planetmaker> :-)
17:25:25  <Xotic750> I missed some renders and the post-processing stopped, so had to render 6 models real fast
17:37:18  <Ammler> planetmaker: and did you also manually start those?
17:37:45  <Ammler> (preferable in the screen)
18:05:23  <Terkhen> hmmm... I made some commits to ogfx-rv yesterday but there is no nightly yet
18:12:27  <planetmaker> Ammler: I started manually ogfx+trains
18:12:35  <planetmaker> it's still building, it seems
18:12:41  <planetmaker> quite lengthy...
18:20:00  <Terkhen> can I start it manually somehow?
18:25:17  <Ammler> it?
18:25:40  <planetmaker> the compile
18:25:46  <planetmaker> Terkhen: not really... it needs ssh
18:25:49  <Ammler> not in screen?
18:26:03  <planetmaker> I didn't use screen this time, I'm afraid
18:26:09  <Ammler> ok
18:26:13  <planetmaker> I thought it would finish up in a few secs and be done
18:26:22  <planetmaker> well minutes
18:26:41  <planetmaker> I'd not mind giving you that ssh, though, Terkhen
18:28:50  <Ammler> started scheduler in screen
18:29:45  <planetmaker> a 2nd scheduler?
18:31:42  <Ammler> no clue, just deleted the queue, did you do that?
18:34:27  <Terkhen> planetmaker: thanks, but there is no need for ssh access, I just would like to post about the new feature and for that I need a nightly, but I don't think I would use ssh besides today :)
19:18:51  <Brot6> ogfx-trains: update from r479 to r568 done -
19:28:06  <Brot6> firs: update from r2851 to r2854 done -
19:31:46  <Brot6> cets: update from r675 to r680 done (187 warnings) -
19:34:27  <Brot6> dutchtrains: update from r571 to r583 done -
19:35:36  <Brot6> make-nml: update from  to r13 done -
19:39:30  <Brot6> ogfx-rv: update from r144 to r146 done -
19:42:45  <Brot6> grfcodec: update from r932 to r935 done -
20:10:18  *** Xotic750_ has joined #openttdcoop.devzone
20:14:05  <Terkhen> nice, a nightly :)
20:14:11  * Terkhen prepares a post
20:14:38  <Brot6> bandit: compile of r489 still failed (#3900) -
20:45:52  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: bros (1 warnings), opengfx, transrapidtrackset (Diffsize: 6), 2cctrainset (78 warnings), cets (187 warnings), worldairlinersset (Diffsize: 6), heqs, basecosts, water-features (Diffsize: 6), isr (2 warnings) (Diffsize: 1367), 32bpp-extra (2 warnings), newgrf_makefile (Diffsize: 1), snowlinemod, britrains (10 warnings), fish, ttrs (7 warnings),
20:45:52  <Brot6> ogfx-trees (Diffsize: 6), smts (Diffsize: 14), chips, comic-houses (3 warnings)
20:56:52  *** ODM has quit IRC
21:06:14  <Brot6> OpenGFX+ Trains - Revision 569:c3bd8bb57c98: Fix: Incorrect output directory was overwriting mono_fl... (graham@moonshot) @
21:33:28  *** frosch123 has quit IRC
21:37:10  <Ammler> is there also a release build pending?
21:57:23  <planetmaker> not sure. I deleted that, too when I deleted all those queues. Maybe now?
22:03:24  *** Xotic750_ has quit IRC
22:32:42  *** Nat_aS is now known as Nat_AFK
22:45:44  *** Nat_AFK is now known as Nat_aS
23:41:34  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk