Messages

16

[Max] Daily Builds / Re: Daily Builds

« on: 2016-02-19, 08:58:18 »

Hello, some thoughts on your problem. Well, even if it very much depends on the bitmap used in bump slot, still I rarely go above 0.1 values for materials such as these - it surely does look that for some reason it just wasn't working in previous releases cause the value of 70 should produce such or even more exaggerated and unnatural results and I'm quite surprised it did produce such a relatively timid result with that value in the latest build which makes me suggest that, somehow, the max's bitmap loader changed\messed up gamma input settings so just try to change input gamma manually and see how it fares then, still it is really hard to tell without seeing the actual bitmap itself.

Thx for your post, pling with input gamma does not give significant result. I attach a part of the texture, so you can play too if you want.
This morning I have some test. Using this texture as bump, any bump value from 10 to 99 give a little difference. Little difference from 5 to 10. Significant difference from 5 to1. Important difference from 1 to 0, I find this map usable at about 0.02 or 0.01
Is it me, is it the map, or bump scale factor have to be adjust a little?

17

[Max] Daily Builds / Re: Daily Builds

« on: 2016-02-18, 10:25:43 »

This may be a silly suggestion but try removing the bitmap node completely and loading the map in a new node, then check if it works better.
I say this because when moving to new releases there has been some times when the bitmaps were corrupted and I had to reload them.

Cheers.

Thanks for the idea, but same result.

18

[Max] Daily Builds / Re: Daily Builds

« on: 2016-02-17, 16:11:05 »

Using last two daily builds, I'v got some problems with bump map value, I've just turn from 60 to 0,01 and finally I disable it otherwise my wood floor seems to have canyon inside.. just me?

What kind of bump map is that? Greyscale or rgb normal map? So you switched from 1.3 to the daily builds and there was this difference?

No, I switched two days ago from 2015-12-19 release (I think, I'm not fully sure) to 2016-01-27, the same with the last one.
Bump map is a rgb JPG. I attach the difference I've got with the same map on different release.
Actually, it seems bumps doesn't work with the old release (please don't ask me how couldn't see it before...), but with the 2016-02-16 it works too much! a value of 0,01 and you can see a signed bump, imho is a little out of scale.

I'm sorry I can't be 100% sure about previous release I was using :(

PS: feel free to move this conversation in a more appropriate thread.

19

[Max] Daily Builds / Re: Daily Builds

« on: 2016-02-17, 11:11:08 »

Using last two daily builds, I'v got some problems with bump map value, I've just turn from 60 to 0,01 and finally I disable it otherwise my wood floor seems to have canyon inside.. just me?

20

[Max] Resolved Bugs / Re: Light visibility with directionality

« on: 2016-02-16, 12:29:41 »

I'm talking about having the best result with the minimal work.
And it seems I'm not alone in this .. ;)

No you are not. Need physically correct directional light?
Do nothing.
Need did rectional light to be visible from all angles?
Sacrifice 5 seconds, rightclick rayswitcher and apply to GI, copy material with 0 directionallity to direct override.

Of course, my dear (maybe young?) friend. But, this is your opinion. That I respect. Maybe you shoud learn to respect the other one too ;)

21

[Max] Resolved Bugs / Re: Light visibility with directionality

« on: 2016-02-14, 13:20:17 »

In real photography, when you want to create directional lighting, you apply for example a grid modifier to your light source.

Something like this:


When you look this light source from the side, you will see only black, because of the modifier.

Of course it's true, but we can go over this kind of limits with render, why not?
As I've already say, often, most of all in conceptual renders, it's so usefull to see source place of a light, no matter its dirtectionality. I'm not talking about phisical or not phisical correct, I'm talking about having the best result with the minimal work.
And it seems I'm not alone in this .. ;)

22

Hardware / Re: CPU for Corona

« on: 2016-02-12, 15:52:42 »

Googled E5-1650 v3 sse4
This is the most basic stuff. Literally took me 15 secs to Google.

Thx for your support, and for your 15 sec. too, ;)
Alessandro

23

Hardware / Re: CPU for Corona

« on: 2016-02-12, 12:54:41 »

Thanx for the info, actually I've already read almost everything about Intel CPU, the information I need is not his technical sheet, but what Corona needs (I mean the MUST) to work fine  ;)  (to be clear, for example I've got some old quad core that does not support SSE4 set, Corona told me when I try to install in that pc, so this is a must)

I've a doubt about this, maybe you can resolve my question: in this link
http://cpuboss.com/cpus/Intel-Xeon-E5-1650-v3-vs-Intel-Xeon-E5-1650-v2
ther's a comparison between Xeon E5-1650 v3 and E5 1650 v2 , V3 seems to not support SSE4, is this a sub set of other supported set of instruction? (sorry, my hw knowledgment stop a little before this ;))

thx again,
Alessandro

24

[Max] General Discussion / Re: Corona Alpha4 Benchmark scene

« on: 2016-02-12, 12:40:28 »

Corona Renderer Alpha 4 benchmark scene
 Living room 100 passes
Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz
Time: 0:4:25, Rays/s: 4,800,814

25

Hardware / CPU for Corona

« on: 2016-02-12, 10:56:11 »

Hi,
I'm configuring a new ws I'll use with Corona.
I'm oriented on E5-1650V3 as CPU, my question is: instructions set of that CPU (AVX 2.0) is fully compatible with Corona?
Does anyone has got some experience with this CPU?

Maybe Corona team could prepare a short list of must for a good ws, please pleease please ;)

Thanks a lot,
Alessandro

26

[Max] Resolved Bugs / Re: Light visibility with directionality

« on: 2016-02-12, 09:45:45 »

Light Object and Light MTL applied to the same material are the same thing. There is no difference between CoronaLight and CoronaLight MTL, except user interface.

Yes. And I find more usable light object interface than lighted surfaces for a lot of reasons.

27

[Max] Resolved Bugs / Re: Light visibility with directionality

« on: 2016-02-11, 15:10:36 »

.. :| really, sorry, but I can't understand what you mean. Can you please explain me better what you suggest me to do?

The cheap solution is to apply the Corona RaySwitcher Material to the Light. I presume your light is a cricle, so get a small circle/disk and apply it. In all the slots you put a corona light mtl with the same settings as the light. At this point you have the light casting like it did before, nothing change, same look, same performance. now you apply to the direct ovveride, reflection and refraction the same lightmtl, but with 0 directionality.

What you get is a light that looks like a 0 directionality light, you see it from every angle, in reflections and refractions as well, but the light itself casts a directional light.

Thx for your long explanation, actually I was talking about a Light object, so I couldn't understand you ;)
It's all right for a surface with light material, your way works fine.
Best.

28

[Max] Resolved Bugs / Re: Light visibility with directionality

« on: 2016-02-11, 11:42:43 »

Rayswitch a self illum material in direct override slot, 0% performance loss, no geometry needed.

.. :| really, sorry, but I can't understand what you mean. Can you please explain me better what you suggest me to do?

29

[Max] Resolved Bugs / Re: Light visibility with directionality

« on: 2016-02-11, 10:33:14 »

Yes, exactly as I'm doing now. But it's a big annoy, I have to add a geometry, and move it with the light if I need to move the light, and so on...
I agree with Ondra, web described in IES file depends by a lot of value, maybe the most important is the shape of the light bulb and the shape of the "case" of the light. So, actually, if point of view is out of the web, light source is not visible.
But.
When I prepare conceptual render I often need this kind of solution. It could be very useful to have the capability to force light source visibility. And (Ondra, I apologize for the next words...) I think it is not thousand rows of codes :|||| (ok, I'm joking Ondra, don't be angry;) )


It's just me? If it's, ok, I'll go on with creating a lighted surface above the light.

30

[Max] Resolved Bugs / Light visibility with directionality

« on: 2016-02-11, 09:09:19 »

This is not really a bug, but imho an incorrect way to manage light visibility.
See attached pic, using a directionality value >0 cause the light source become invisible out of the cone of directionality. Always, when I use a visible light I need to always see it, in this moment I have to add an auto illuminated surface to be sure to see light source.
Maybe there should be a flag to define if the light source is always visible with any directionality value.