Times are UTC Toggle Colours
01:10:37 <Brot6> OpenGFX+ Trains - Revision 559:e2b2c9a56b49: Add: Render run of passenger, mail and armoured wagons (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/e2b2c9a56b49 01:11:11 <Brot6> OpenGFX+ Trains - Revision 560:7d96ee58dd12: Add: Post-processed run of passenger, mail and armoured... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/7d96ee58dd12 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, http://paste.openttdcoop.org/show/1425/ 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> https://munin.openttdcoop.org/openttdcoop.org/haydn.openttdcoop.org/cpu.html <-- 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 http://paste.openttdcoop.org/show/1425/ 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/adac85d9d382 11:35:43 <Brot6> OpenGFX+ Trains - Revision 562:ff45b5753ea1: Add: Render run of all monorail flatbed wagons (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/ff45b5753ea1 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/c8c504fd33e7 15:46:11 <Brot6> OpenGFX+ Trains - Revision 564:0109cc2b45b2: Add: Render run of monorail tank wagons + 1/2 the post-... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/0109cc2b45b2 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/684979310d09 16:12:50 <Brot6> OpenGFX+ Trains - Revision 566:f6e9f7c76071: Add: 8 sprite loading template for wagons and vehicles ... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/f6e9f7c76071 16:14:29 <Brot6> OpenGFX+ Trains - Revision 567:954913459501: Add: Prepared nml for future open door loading sprites (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/954913459501 16:16:11 <Brot6> OpenGFX+ Trains - Revision 568:d92c43d97e7a: Feature: Make use of 32bpp sprites (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/d92c43d97e7a 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 - http://bundles.openttdcoop.org/ogfx-trains/nightlies/r568 19:28:06 <Brot6> firs: update from r2851 to r2854 done - http://bundles.openttdcoop.org/firs/nightlies/r2854 19:31:46 <Brot6> cets: update from r675 to r680 done (187 warnings) - http://bundles.openttdcoop.org/cets/nightlies/r680 19:34:27 <Brot6> dutchtrains: update from r571 to r583 done - http://bundles.openttdcoop.org/dutchtrains/nightlies/r583 19:35:36 <Brot6> make-nml: update from to r13 done - http://bundles.openttdcoop.org/make-nml/nightlies/r13 19:39:30 <Brot6> ogfx-rv: update from r144 to r146 done - http://bundles.openttdcoop.org/ogfx-rv/nightlies/r146 19:42:45 <Brot6> grfcodec: update from r932 to r935 done - http://bundles.openttdcoop.org/grfcodec/nightlies/r935 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) - http://bundles.openttdcoop.org/bandit/nightlies/ERROR/r489 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/c3bd8bb57c98 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