Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - antanas

Pages: 1 [2] 3 4 ... 19
16
Gallery / Re: Meteora
« on: 2017-03-17, 18:52:15 »
Man, you really do have some talent, a good taste and of course skills to accompany those ) That's not some regular archviz stuff which we usually see and produce ourselves, that is art and a good one at that and more than that it has style too - good job !

17
[Max] Daily Builds / Re: Daily Builds 1.6
« on: 2017-02-26, 15:41:02 »
@romullus and everyone interested in decent looking barrel and fisheye distortions - custom texture distortion maps are a way to go if you want to get a decent and non pinhole like ones the cubic one produces - after studying this https://knowledge.autodesk.com/support/3ds-max/learn-explore/caas/CloudHelp/cloudhelp/2016/ENU/3DSMax/files/GUID-71FF38CD-07E4-419B-A8AF-69CE101182A0-htm.html and the provided sample I realized those distortion maps are in fact just a normal maps without the blue channel so it's not too hard to model a sphere representing the lens curvature, make a render from a 200 or more mm camera pointing straight at it like this http://c2n.me/3HTMABp + making a zdepth pass with min distance just before the front of the sphere and the far one at around the point your camera view cone intersects the sphere - this way you get some nice displacement texture out of it (btw I use this simple method for any quick and effortless displacement map extraction) after that you just need to convert that displacement map into a normal map using any of the normal map making software out there (I prefer Knald) and voila - after some rotation and contrast tweaking you get yourself a nice normal\distortion map which can make http://c2n.me/3HTNvbq distortions looking like 1 rather than the ugly 2 )) See the attached distortion map I made - to get the results similar to the one I posted, simply up it's contrast either in photoshop or by putting it through 2 ColorCorrection modifiers - 1st with a 100 contrast and the second one at around 55.
Anyway this method is of course not accurate in any way but you can make ANY kind of distortion maps this way, even some funky and totally unrealistic ones just be aware that those maps should have the same image aspect\proportions as the render resolution has - that particular one I made is made for 1.0, well 2000x2000 etc .
 
edit: To think of it - probably some simple displacement map made in photoshop by using some of the round, blurry brushes and using white color to paint over a black background will work just as well as the displacement map extraction method I mentioned above - well, anyway, the more the merrier ))

18
[Max] Daily Builds / Re: Daily Builds 1.6
« on: 2017-02-25, 20:55:32 »
@denisgo22 well I complained about that too (see https://forum.corona-renderer.com/index.php/topic,13401.330.html post Reply #334) Juraj and my pal Flavius agreed on that but that's it no one else either noticed or use DR on the newer dailies hence didn't notice and even if Ryuu called that afaik (which of course may be not too far from truth) some posts later it still happens in both our cases and I surely don't want that feature to be left without some sort of an ON\OFF switch for even if we both did mess something up (which I somehow doubt) DR was behaving better previously - there were no such delays due to that additional asset sending etc not to mention the ssd\hdd cluttering.
 Anyway in case it's our network\corona\admin rights setup fault lets check our settings - I use win 10x64 ultimate, mapped network drives from my main pc so they appear the same D,E,F,G,H and the rest across all my 4 pcs, all those pc's have the same admin user and same password and all are in the same workgroup linked via uncontrolled 1gb switch - well nothing unusual and it works without any problems for years never missing any texture when using dr and without any need to set network paths or any such nonsense when I work. I run max as admin and run corona's DrServer as admin too and same for all pcs so there shouldn't be any issues with that either.

19
[Max] Daily Builds / Re: Daily Builds 1.6
« on: 2017-02-13, 15:13:11 »
@Ryuu hmm it seems to me it does but will test it more thoroughly this time - maybe some of dr nodes hadn't refreshed the mapped drives for some reason and thus the sending of everything happened, anyway if it's not already done (maybe it is there and I just hadn't noticed that), some warning about the assets being unreachable by dr nodes could be shown in coronas log window that would surely be welcome in any case - no need to show all unreachable assets - simple warning like warning DR-pcname assets unreachable or something like that would suffice. Plus it would be pretty cool if you could implement some forced mapped drive refresh command to DrServer application which could be run when it starts or even would be run constantly with some interval after it starts - there are such commands which can force refresh the connections to those drives but why goddamned Microsoft didn't address the startup reconnection issue for years remains a mystery to me. Plus if it could report if that reconnection failed (I mean if there's some uconnected drives left on that dr node pc after the command is run) in corona's log window on main pc it could be even cooler but not too necessary )) - there are some 3rd party soft for that but it would be good if Corona could do that by itself just in case - foolproofing it all the way to the top so to say ))

20
[Max] Daily Builds / Re: Daily Builds 1.6
« on: 2017-02-11, 20:34:26 »
Tested the new DR a little too, well, mostly it is on the right path, I really do like the pre run 3ds max function )) But I REALLY don't like the non configurable automatic sending of textures, proxies and other assets in the new DR implementation, well I mean it's probably nice to have such capability for some people who are unaware of network drive mapping or automatic directory cloning or for the ones storing their assets on system drive (lol), sure, but when the network and the asset paths are set up in a decent way it takes some unnecessary additional time to send all that once again instead of just reading\sending it using OSes own functionality like it did previously which can take quite a while on some heavier scenes not to mention the additional hdd space waste which again might be unnoticeable on smaller scenes but can be quite a problem if say some 10 gigabytes of proxies containing scenes are involved or something like that.
So I would surely want that feature to have an on\off switch in the DR settings window\tab for I, personally, don't see any benefit of using it for in my case it just slows things down quite a bit.

21
[Max] Daily Builds / Re: Daily Builds 1.6
« on: 2017-01-14, 19:08:26 »
Stop or Cancel button not working...I cant stop or cancel my render.
Happened to me to twice or trice - not sure if it's new DR related or not (for it did happen in the past too) but this time it happened when I used it. Btw the new DR will be awesome after some polish ) 

22
[Max] Daily Builds / Re: Daily Builds 1.6
« on: 2016-11-16, 17:09:38 »
Speaking of improving and stabilizing - there is one thing which bothers me for quite a while.....
Could you send us instructions how to reproduce this? You could contact us about this at https://coronarenderer.freshdesk.com/support/tickets/new

I read your post, but still did not understand fully what was done here, and how to reproduce this. Just two guesses:
1. Maybe it has something to do with the wrong UHD Cache settings in 1.5? Have you tried this in 1.5.2? ("reset settings" in scene setup is required for the UHD Cache to work correct if the scene was previously saved with wrong settings!)
2. Did you drastically increase or decrease light intensities in LightMix? If so, then this is expected. LightMix should be used mainly to change lights' color, or to change their intensity only subtly.

Hi Maru, well, the easiest way to reproduce it would be to download those scenes I attached to that post, there are both default sun and sky value one and the one with lowered ones but every (and I mean every scene not necessarily made by me))  exterior + interior scene with lights setup using the real world values which manufacturers often provide would be good for that test too
1. I would suggest it's not a bug at all + it has been there for ages, it's just that it's easier to see it now because of the lighmix being added. So to make it as clear as I can - that's not some corona version specific bug but rather a way corona's gi currently works, giving some sort of sampling priorities to the brighter light sources so and sun and sky being way brighter than the others (usually 1000times brighter than the rest of the physically plausible setup light source) leads to that all the time, but even if i'm wrong and it is a bug, then it was present in all prior corona versions too, but I've been able to spot it clearly only when the first pre 1.5 lighmix containing builds showed up and of course it is present in 1.5 , 1.5.1 , 1.5.2 and even in that early 1.6 daily.
quote "reset settings" in scene setup is required for the UHD Cache to work correct if the scene was previously saved with wrong settings!" did that too, even if I did that after doing those tests on both 1.5.1 and early 1.6 - no difference there, as this is most probably not UHD cache related thing at all, although after resetting, it sure did a better job on those splotches in the corners of that "room", even way better than setting uhd precision to 10 in the previous builds which I actually had to do when doing those tests, but still, it does not effect that patch tracer produced noise at all.
2. well I had decreased sun and sky's values in lightmix to get some sort of decent sunlinght intensity without lowering exposure (which would kind of ruin the test's purpose) and increased those when doing test with lowered sun&sky values to compensate for that initial intensity decrease and of course set sun's pass to 0 and decreased sky value and added some dark blue color to it in both cases to get those night like renders. If I didn't completely misused the lighmix the whole time )) it is imo the whole point of using it, well, to get those nice night\evening with artificial light and day (without the one) renders out of a single render ) Still decreasing or increasing lighmix channel values does not effect the noise amount at all + I rendered all of them with the beauty pass active if that makes any difference at all + I think there should be any difference either as if I got it right the lighmix is kind of more like mixing different layers in photoshop than anything else right now so there should be no impact on any kind of sampling and only the initial light source intensity does have that impact there which the test proves quite nicely, well of course, if I wasn't completely stupid and did some incredibly stupid mistakes in the whole overthinking of that process )) Well you surely begin to see some "undercooked" layers when you lower the lighmix value for some bright light source which otherwise obscures the rest of the not as bright ones thus masking their noise but that was the whole point of that test - to see how the changes in the initial brightness values of the sun and sky (not the ones set in lighmix but the "real" ones)) effect the gi sampling in general.

 So trying to sum it up - decreasing the initial (pre render not lighmix's) intensity values of corona's sun and sky to somewhere around 0.01 can have great benefit for the sampling of interior lights when render is done from the outside of that building model which is especially apparent when there's some glass in windows etc. , thus, greatly increasing the noise coming from those interior light sources cleaning speed in such type of the scenes. It can be seen only when one is doing some lighmix adjustments to the initially daylight+sun lit renders making those renders to represent different lighting conditions afterwards, namely doing some night or the evening type of lighting, if there are no interior lights or if the sun and sky values were initially set to represent the night\evening scene there's no difference at all which is kind of expected.
 And finally, to better illustrate the benefit of that trick\needed tweak of corona's PT gi system I post the first results I got using that technique on a production scene I worked on earlier. Those tests with a room full of teapots, what I posted before, were done after these in hopes of clarifying\proving that benefit in a "clean" and more or less controlled scene. So here goes:

1 the render using default values of corona sun and sky which rendered for around 45 minutes
https://www.flickr.com/photos/119850875@N05/31027982325/in/datetaken-public/ - daylight lighmix preset
https://www.flickr.com/photos/119850875@N05/30725862970/in/datetaken-public/ - night lightmix preset - notice the ugly noise inside the interior which didn't go away even after I rendered some region of affected area for additional time almost doubling the pass count for that part
https://www.flickr.com/photos/119850875@N05/30991942826/in/datetaken-public/ - sampling focus pass for that one

2 the same scene with slight adjustments with some additional exterior light fixtures and slightly different view angle (nothing else changed and I doubt that adding those 2 lights would benefit the render speed at all, well, this scene was not intended for testing purposes so you know how it goes) rendered using lowered to 0.01 sun and sky values for around 15-20 minutes (pay attention to that)) when bringing those values up back using only lighmix after the render was stopped.
https://www.flickr.com/photos/119850875@N05/31027971085/in/datetaken-public/ - daylight lightmix preset
https://www.flickr.com/photos/119850875@N05/25391535069/in/datetaken-public/ - night lightmix preset - notice the ugly interior noise gone ))
https://www.flickr.com/photos/119850875@N05/30726015030/in/datetaken-public/ - dusk\evening lighmix preset, just for the sake of it )
https://www.flickr.com/photos/119850875@N05/30992083856/in/datetaken-public/ - sampling focus pass for that one

So you can easily see why am I so agitated by my findings and if those can be proven and reproduced by someone else it could mean what some slight adjustments to corona's gi behavior could make it much (can't calculate how much but A LOT) faster than it currently is when dealing with such a scenes. To make things better, daylight + artificial light interior scenes like this benefit from this trick as well when rendered from inside the interior itself, yet I have no images to prove it cause I hadn't done some specific test for those and the one's I have rendered were done on that same production scene after using that trick, but the interior itself was changed quite a bit since the times I rendered the same views without this trick, sadly have no time to do more tests right now but still it would be good if anyone could reproduce it, well at least to prove what I haven't gone mad completely ))





23
[Max] Daily Builds / Re: Daily Builds 1.6
« on: 2016-11-10, 16:57:51 »
Speaking of improving and stabilizing - there is one thing which bothers me for quite a while and it is the sampling of lights and GI which they produce when those are put behind the glass both solid (refractive) and thin alike.
 Recently I've been struggling with one scene which had fully modelled interior with furniture lights etc. + sun and sky + some lighmix combinations to represent the different lighting conditions - well the usual stuff. At some point I needed to do some exterior shots of the place and I had run into tremendous amounts of noise which was very persistent in the interior visible through the windows when it was rendered from outside and the lighmix pass combo's were set to represent either night or evening lights. I did some testing cause I've got a hunch that it has something to do with the way corona's gi sorts the priority\importance of lights based on their brightness and so sun and sky being around 100% more bright than any physically correctly setup interior light source takes away all the samples\priority\whatever leaving other light sources only tiny leftovers of that. Guess what, it seems, that was the right hunch, and after lowering both sun and sky intensities to 0.01 I've been able to get much cleaner interior in MUCH less time - here's some examples of the similar situation reproduced in a clean scene and hopefully clean conditions :

https://www.flickr.com/photos/119850875@N05/30780770972/in/datetaken-public/

and the same both renders with lighmix set up to represent the day with the interior lights off

https://www.flickr.com/photos/119850875@N05/30261488543/in/datetaken-public/

Anyone wanting to check more of those tests and different passes saved out of those is welcome to explore this - https://www.flickr.com/photos/119850875@N05/albums/72157676287977736 album - I've done a couple of tests with different glass settings and without the glass at all, adaptivity on\off etc. the naming of files should be self evident I hope. Pay close attention to the sampling focus passes (SF) and how they differ across the different setups.

I'm almost sure it's not the best way of dealing with such conditions, physical correctness, energy conservations etc. wise, and of course it would be better if corona's GI system could\would be tweaked internally to alleviate the need of such stupid methods but it still helps me a lot to get those renders cleaner and much faster, and I'm most sure it will benefit many people who struggle with such setups as well, mainly because that nasty noise will not go away even if those images will be rendered for an hour or so, which I tried of course even if not in this particular test scene.
I wasn't sure how and where to put this report as this, most probably, is not a bug at all but is something more like a trick or just some needed internal tweak + I'm not completely sure (and who can be))it's not something wrong on my end thus it might be best if someone could reproduce such behavior too and report it too. And there's another thing inside those tests which is ligh source's disk shape being invisible behind refractive glass and visible when thin(non refracting) glass is used  but that's not too big of a deal cause no one usually leaves those exposed such as here, yet still there it is ... So hoping I didn't make a fool out of myself again I post my findings here ))

Actually, It is quite easy to reproduce and everyone can test it for themselves but I'm still attaching that test scene (max 2017 and 2015) with both default and lowered sun and sky values + those lighmix pass presets for each of the scenes - no textures were harmed in the making of that test scene and the only ies file used in it is the default one which comes with 3ds max and was there for ages so hopefully it will be picked up automatically.

24
[Max] Daily Builds / Re: Daily Builds 1.6
« on: 2016-11-07, 15:27:59 »
Good news, as long as it will be done using openCL and not the amd-gpu-user-butthurt-inducing Cuda ))

25
[Max] Daily Builds / Re: Daily Builds 1.6
« on: 2016-10-31, 12:58:41 »
Oookay then, so currently it's not even possible to add those non emitting CoronaLightMtls to the same LightSelect element (or any other besides the Rest(unassigned) one) where the rest of the lamp's lights are put too ? That seems a little strange considering they can be put to Rest(unassigned) because of which, one might think that's just an overlook in lightselect's "+" functionality, but I'm no programmer and I cannot completely understand the reasons behind it if it isn't. Well If it is so, it's a major showstopper then, well, at least, to some degree, it's good to know those are not some recent and unexpected bugs\limitations so at least I can try to adjust my workflow to somehow avoid using those and that those workflow adjustments will be at least valid for some time - the question is how to do that and for how long but that's another matter. 

26
[Max] Daily Builds / Re: Daily Builds 1.6
« on: 2016-10-30, 17:15:53 »
Had run into some troubles using lighmix + Light emitting materials - not sure if those are a bugs, some combination of those + some intended behavior or some stranginess in the way I work + I cannot think of how to put it on mantis separately as those 3 are somewhat related (or at least in this particular case) and wouldn't make such an impact if described one at a time so here goes: 

1) Corona lighmix LightSelect ignores all the materials\objects containing CoronaLightMtl with Emit Light ticked off both in manual and automatic creation modes. Same goes for the regular CoronaMtl with some Self Illumination but that is not the problem cause i don't know who in their right mind uses those.
 It is quite senseless, especially in case of grouped lamp fixture models which containin, say, some light bulbs or even some filaments within those bulbs which contain such non emiting materials and Corona or standard light objects for the actual lighting itself, all of which, logically, should be controlled by\contained in the same light select element to make brightness adjustments\dimming of that lightSelect pass for the that whole lamp model at the same time. Because of this behavior, those light bulbs\filaments cannot be dimmed with the rest of the lamp fixture using the same element's slider and it's quite easy to guess the rest, speaking of which - the Rest(unassigned) lightmix element does pick them up automatically but that's surely not the most convenient way to control those I think.

2) CoronaRaySwithMtl does not respect the Emit Light tick on\off in CoronaLightMtl if that material is put into Global illumination override slot - it presumes what it is always ON, on top of that if it is off it produces light but those material's emitted light\gi is sampled in a very weird way and i mean really WIERD way - it's easily reproducible so you can see what I mean.
This can lead to some unexpected and quite nasty behavior in some cases - yesterday, I've spent almost half a day trying to figure out where that nasty, unexpected and unyielding noise is coming from in my currently worked on scene and in the end I've found this to be responsible for it.

3) CoronaRaySwithMtl and CoronaLightMtl again. When Emit light is ticked ON inside the instanced CoronaLightMtls which are put in all the slots except Global illumination, which in turn contains no light emitting material or left empty, the whole CoronaRaySwithMtl renders black, same goes for Self Illumination containing regular CoronaMtls. Not sure if that's a bug or an intended behavior but it surely doesn't make too much sense to me, especially in a regular Self illumination containing CoronaMtl's case - I don't use the latter, though but it can be still encountered due to some quick conversion from vray made models whether one wants to use it or not. Still that bug\behavior wouldn't bother me at all if not for combination of (1)+(2)


4) or partially more like extension of 1+2+3. Well, I thought, and it seemed pretty logical to me at the time, what as a temporary solution to battle (1), I could use CoronaRaySwithMtl containing instanced CoronaLightMtl with Emit light ticked ON in all slots except Global illumination slot, leaving it empty or with some non emitting material to battle (2) along the way - it should allow LightSelect element's "+" function to be able to pick those objects\materials. Well, it does help, at least with the picking\adding to lightselect element part, except the material itself renders black due to the (3) so in the end it does not help at all.

So to wrap things up or why it bothers me so much - partially I described it in (1) all I can add to that is what having light emitting light bulbs not to say light emitting filaments inside the glass bulbs is a most sure way to make one's renders longer, waay longer + it can lead to some various but all nasty artefacts if the geometry of those bulbs\filaments is not perfect - which is often the case with too much of 3rd party 3d models nowadays (
Thus, the most important for me would be the fix for (1) and if that can be fixed all others are less important. If for some reason (1) cannot be fixed when fixing either (2) or (3) or even better both of them should do the trick. And, of course, it would be best if you could fix them all, for the greatness of Corona, of common sense and for all which is good in the world ))

27
Thanks, both of you - Cmpp, here I come )

28
Yep, but even the demo will suffice.

29
[Max] Daily Builds / Re: Daily Builds 1.6
« on: 2016-10-11, 02:59:45 »
Well that was quick )) And what a teaser pic - reminds me of my once in a lifetime lsd trip, or at least the beginning and the ending part of it - definitely do want that feature ))))

30
[Max] Daily Builds / Re: Daily Builds 1.5
« on: 2016-10-07, 21:29:57 »
@denisgo22 Don't think that's possible due to a how denoising works and that would probably destroy the other lighmix elements with some weird and I mean really, really weird denoise patterns coming from the beauty pass but that's only what I think how it works so it might not be the case. About speed, well I personally have no problems with that as my renders usually take from 1.5 to 3h each (and that's if i'm lucky) and denoising even when rendering 4k with 8 or more denoising enabled lighselect elements takes only a tiny fraction of that time - still it can probably be made quicker if corona's team could make it use openCl (hopefully not cuda for if cuda then it's no go for me and to many other non NVidia people out there) making use of gpu's too for the task - vray for instance does denoising pretty quickly because of that.
What I'm really wondering if adaptivity could be used for those lightselect passes too - that would surely take down rendertimes significantly. But I guess if that could be done as quickly as one wishes, Corona's team would have done that already ) Sadly, for now the difference in noise levels of the beauty pass and the lightselect ones is tremendous due to them being rendered the old way, well, without adaptivity, and that's probably even worsens the chances of a beauty pass's denoising to be usable for lightselect elements due to a difference of those noise patterns.   

Pages: 1 [2] 3 4 ... 19