___

As for the models: SIMPLY SUPERB! I like the way you combined those elements into unique forms, namely glases/canopies - very very nice + overal design/concept is beautiful, congrats (reminds me a bit LEGO's proto-designs of old M:Tron I saw once)! But as for the plot: sorry, but it is soooooo trivial (race traveling space and planets finding a new place for their ever growing numbers whos sun gone supernova some time ago...? Oh, c'mon! ) - unoriginal and for "millionth" time repeated cliche, my friend...you could really come with something better cos such design deserves it really, sorry. (phun intended)

SUGGESTION: - add new entry to the themes list called "PSEUDO SUBTHEMES" meaning all subthemes made up by us, creators/builders

MOC: #691309 Geological Planetary Expedition link: http://www.eurobrick...showtopic=99569 theme: space subtheme: Classic Space / pseudo subtheme "Techtroners" (all MOC - present and future ones - using exactly the same color scheme and design concept) category: vehicle

I was trying - and always am - to base MOC rather upon those old space design concepts and principles which mean being more airy with less bricks, not bulky nor filling every hole with something BUT at the same time trying to implement some new bricks and ideas of my own...hope you'll like it. As for the colors combination: I was trying to come up with something that was never used before and making it my own standard used in all of MOC which evolved to this combination of: - primary color: yellow - secondary colorS: black and white - dark blue trans windows and canopies

OK, so I take the honor being the first one... I render those "many files one by one" when adjusting my POVRay script, so I need to see how it behaves with different MOCs but with the same settings therefore LDD2Povray is open non-stop, just files are changing (as I have them in their own directories, logicaly, where every directory is one MOC)

No stickers at all - FINALY, FINALY, FINALYYYYYY!!! Being really happy having new neo classic minifig in new color of green (so now we have 6 classic space mimifig colors, yayks! ) with our lovely gold planet logo on it (ehm, is it still gold, right??? ) - if for anything else I like this set for this fact alone, really... Can you tell how much it costs down there in Vienna? I could go there - it is pretty close from here near borders - to buy one if it is for a reasonable price...like <= 30€+/-

I have done several of them (some may become vehicle, some may become spaceship, some are just plain moonbases in classic space baseplate range of 1 or 2) but not rendered them yet, maybe later... But what I do not like on the concept is its "over-dimensioned" scale, I rather do bases for "normal" minifigures like those sets from 80's, sorry folks. Hey, that is one perfect moto-base design (although a bit oversized for my taste, but stil superb concept, really!) :thumbup: BTW I did some similar stuff before...have to render it and post also...maybe once.

Click images for FullHD resolution... Find out more on set's official webpage: http://lego.queryen....691309.php?j=en You can see it also at MOC Pages here: http://www.mocpages.com/moc.php/412517 LEGO Ideas direct link (please, give it your support there if you really like it...thanx):

OK, point taken It was just an example (although practically a bad one, I agree) wanting to say that I do not see much hard logic in placing all pov and ini in the directory of the first rendered lxf which coverter makes his output dir for its files (pov/ini) comparing to placing them into directory of the converted file itself (and programatically speaking it is quite easy, isn't it?). Cos if it is able to make difference between dirs in which concrete lxf files are then it'd be more natural placing respective pov and ini in those dirs than decide to place them all "hlava-nehlava" in directory of one such lxf file when it was not defined in sw - I think "logical order of things" should always be ahead of "easy way out" tactics, that is all I am saying. Looks like sw takes always that easy way...aaah, those AIs!

...and this is my result (yet still with the need of manual readjustment of the baseplate for every MOC, but being working on the automation at the moment...):

First of all: I am not complaining, just making point...so calm down, please...I am not picking fight here, OK? Next thing: as one did not specify anywhere any special dir for pov and ini files then logic would suggest that if sw creates .pov and .ini in converted .lxf's directory on its own (why exactly there? depending on your logic it could also making them all in includes dir - which would go much more with the sw logic you have specified here - or anywhere it decides to, ah...this way it just messing up user) it means it creates concrete pov and ini in the directory of every converted lxf, not that it has somehow decided putting everything in that directory of first converted .lxf not telling anything about it anywhere and user is then wondering why...I do not know about you but to me it would makes definitely more sense without need of any vote...logic you've said, right? I do not want to be taken as/or sound aggressive or anything like that but if someone is playing on me that I do not understand some common logic I need to argue and sometimes it may sound rude, but it is not meant to be like that so if it sounds like that I am sorry (it is probably caused because of the fact that english is not my native language so I would use/describe it better in my native language...which in my case is slovak) So I hope it is not a problem and that we understand each other well...

@hrontos here is my smooth transition between baseplane and background "trick" (MOC final version render actually avaiting LEGO Ideas acceptance):

+ I do not know but may it be these are sw bugs? See: 1.) When LDD2Povray makes .pov and .ini files of respective .lxf it places them in the same dir where the .lxf file is, BUT for some reason it places/makes all .pov and .ini files in the directory of one .lxf, probably the first I open (see: when I am testing I normally renders more .lxf one after another without closing LDD2Povray between the sessions...) 2.) If you using your own scene .inc file and there is another one with the same name in directory where LDD2Povray places .pov and .ini file/s for respective .lxf (it happened that for some reason it places them all into one directory) then it uses the one in .pov/.ini directory instead of the "main" one in "includes" folder where it normally should look for it (and actually really it is still looking only there cos when I press the roll menu for Scene .inc files in the sw there are only those ones from the "includes" folder, exactly as it should be but for some reason it acts as I described here) 3.) LDD2Povray indicates POV-Ray "#version v3.6;" in its generated .pov file instead of actually installed v3.7, seems to be hardcoded in you sw, why? BTW: using x64 version 3.2.110.277 and POV-Ray x64 v3.7.0

Well, when I did that before I had some strange side artefacts on bricks (part of bricks glued together, others have like torn/partly missing edges etc.) and when do not use AA at all the image is simply so ugly that is has no use. See, just for clarification: I am not using your technique, just being cought by super quality of your renders specialy trans parts (glases). In fact I am trying to achieve some compromise solution to render all at once, having six-core CPU it is not that bad, so my actual settings (being rendered as we speak) seems to solve most of the problems I had: - trans parts have no more grainy edges - there is no visible gluing of brick parts - I TOOK ONE OF YOUR TRICKS rendering in 2x resolution I need and then scaling it down...seems really do the magic on the trans bricks edges, thanx - having continuous base plane to background gradient with displayed kind of planet's glowing rim and stars all rendered at once in PovRay so no additional editing/composing needed ;) Basically still tuning some details but main work is done...let's say 90% - I just need to write script for the pseudo base plane to be facing camera at the same distance and angle with every render of MOC I do independently of actual camera position and angle.

And, please, can you tell what exact values of AA you set in LDD2POVRAY (...or I guess we are talking about it here? Cos I am building in LDD)?

@bbqqq please cannyou tell me with what settings did you achieve those nice clear transparent parts without any side artefacts? Cos whenever I do render in POVRay using LDD2Povray and nevermind what my settings are I always get grainy edges on transparent bricks...

Well, being scorpio zodiac sign patience is not one of my favorite features... But really, if I understnad it right you are the one "responsible" for this briliant kind of SW, so you could add this simple option, hm? Also for some reason under Settings button there are two useful options being greyed therefore not for use (Import settings & Export settings) - why?

Right: I know that and that was exactly what I was asking for if anyone knows names of those vars but I had to find them myself again, so if no one else knows them and would like to use them here they are (they are defined for every conversion inside concrete .pov file during LDD2POVRay conversion): ldd_camera_transformation ldd_camera_location ldd_camera_distance ldd_camera_look_at ldd_camera_angle As you said I should clarify what I meant by "background" first: you are right that I am not talking about bg in POVRay's terms, my "background" means ANYTHING behind/under my MOC...that said basically I meant "base plane and background combined into one continuos transition", but most of the transition being in base plane cos as I said elsewhere there are some MOC renders that do not show background/sky at all depending on camera angle. Well, I have achieved that smooth transition but in a bit different kind of way described above in my previous post, hrontos Now I am only sorting out some details... BTW: now new problem occures: for some reason nevermind radiosity type or Anti Aliasing I choose I have some strange grain on transparent edges...you can see it on pic in my initial post of this post...why? What parameter exactly manages this? Being lost right now...

UPDATE: Hey, guys, I am almost there - solution seems to be adding second separate plane{} with the gradient only before my reflection plane{}...still playing with it tho.

Please, is there an option to somehow auto-confirm all those annoying small popup windows dealing with confirmation of overwriting existent files and starting POVRay? It is quite drag to always click those 4 dialogues all the time manually, gee...I'm going mad about it now!

Hey guys, thanx for the links but actually I know all of that. Sadly it's not what I want or better said it does not suit exactly my needs, not what I am trying to achieve, see: with every MOC I create in LDD my camera angle and position are different so sometimes...many times, sky is not even visible because of used camera angle, therefore solution with sky gradient would not work for me...I know it as I was playing with it some time before, sorry... Also pigment does not work for background, it can be solid color only, so that one is also "no-go"... Maybe base plane gradient would work but I was not able find out the right script/syntax for this as I am using also floor reflections with "while()" iteration that seems to be in conflict with gradient for base plane...or at least I do not know how to do it right at this stage of knowlege of POVRay scripting code syntax (as I am programmer but in different languages)... GOOD NEWS Last night after posting this post I was playing quite hard with the script till 03:00 morning... ...and successfully made what I wanted...in a way ...I made simple polygon via POVRay's script containing my pre-made background.png that I've placed and rotated in appropriate coordinates BUT now I am facing new problem: as I said above my camera angles are changing all the time with every render so when I place such rectangle for one set with specific camera angle and position and then use it for another MOC it is out of right coordinates - polygon, basically a simple rectangle, is in wrong position not facing camera. Sooooo now I need to know how to obtain camera position with every MOC I am rendering and then I can use those values to make code that would make my bg rectangle always facing camera in right position and angle... Therefore new updated/related question: does anyone know how to obtain camera coordinates/values via POVRay script?

But that is exactly what I am trying to avoid: finishing/adding bg in some external SW + except that as I am using reflections on base plain there is no option having both bg transparent and also just those reflections, there is only option having transparent sky part with solid base plane and yet if you looking at model from specific angle it may happen that sky is not visible at all thus having solid bg again.

Does anyone know how to achieve gradient background (if possible at all) in POVRay's script? "Normal" solid color script looks like this: background { color rgbt <100/255, 100/255, 100/255, 0> } I did try every possible combination with texture{}, pigment{}, gradient y{} and color_map{} but no success - POVRay stops at this script part all the time so even I miss something important or there is no real option for gradient background in POVRay. Reason for this is that I would like to replace my existing "space" background in MOC that I need to make additionaly in external SW after rendering in POVRay (see below) with two-color gradient...cos I really like those backgrounds in 80's LEGO sets catalogues (mainly Classic Space).

Well, in fact I have made some myself now, later I can .zip/.rar it and share here with others if they find it any useful...actually I am not looking for minifig torsos rather bricks (looks like I already have all I wanted) but @hrontos described it quite exactly, thanx "kamaraaaaaat'. BTW I do not understand what had hrontos wrote differently than me that made you undertand what I really meant, gee... P.S.: still did not find out how to upload file with the message...not a link to external file, but upload it to eurobricks.