OTOY Forums

Equal emitter intensity seems to misbehave.

Emitted light seems dependant on the mesh's original size and seems to ignore any scaling.

So its like putting partly closed shutters on a light source but increasing the intensity to compensate.

Additionally IES lights don't behave properly it seems

Isotemod wrote:Equal emitter intensity seems to misbehave.
Emitted light seems dependant on the mesh's original size and seems to ignore any scaling.
So its like putting partly closed shutters on a light source but increasing the intensity to compensate.

afaik this is the intended behavior, or at least it is like octane works. the only difference is, that octane gets the mesh now correctly scaled. always. like as if you would export it to the standalone. and there is no difference in the intensity of an emitter wherever and how ever you are rendering it (plugin modes/standalone). that's all i can do.

that a sphere with a diameter of 10 emits the same amount of light like a sphere with a diameter of 100, when both have the same power is ... apparently the intended behavior and was working not as intended in the previous versions, therefore there were differences.

Isotemod wrote:Additionally IES lights don't behave properly it seems

because of the update, or in general? only if placements are used, or always? an image could be of help...

Sorry IES lights dont appear the same between the standard and Final render modes.

My guess is something alters either the originating point of the IES light or the direction it is emitted.

An image of the final mode is basically an unlit scene.

I'll see if I can produce a before and after of an IES light in an enclosed box.

Isotemod wrote:Sorry IES lights dont appear the same between the standard and Final render modes.
My guess is something alters either the originating point of the IES light or the direction it is emitted.

well, i do already smell where this comes from...

Isotemod wrote:An image of the final mode is basically an unlit scene.
I'll see if I can produce a before and after of an IES light in an enclosed box.

would it be possible to a) have this compared with any previous version of the plugin and b) in particular with the standalone? from my pov the requirement would be daz plugin "final" = standalone through export. and daz plugin "fast/standard" needs to give same results then "final/standalone", if possible at all...

It seems its the rotation of the mesh emitter throwing off the position of the IES light.

1 render uses the facing of the emitter material as intended the other....uses something else.

Animation of lights within a scene or simple repositioning of them is currently impossible in final mode.

Isotemod wrote:It seems its the rotation of the mesh emitter throwing off the position of the IES light.

is both, the emitting object and the ies orientation rotated? if so, my guess would be, that again the use of placement nodes does affect the emitter orientation differently. this is out of my control. i may add an additional switch to render animations still with multiple meshes for those who need ies lights - will need a few days coding and will work... no problem; the speed gain from combining meshes will be of course gone - can't provide both, if octane doesn't take care to calculate those emitters equal internally.

Isotemod wrote:1 render uses the facing of the emitter material as intended the other....uses something else.

?

Isotemod wrote:Animation of lights within a scene or simple repositioning of them is currently impossible in final mode.

you mean if an ies map is applied...

May have caught a bug.

It seems that zdepth (and possibly other special passes) is not being effected by DOF settings.

JeffGalloway wrote:May have caught a bug.

It seems that zdepth (and possibly other special passes) is not being effected by DOF settings.

honestly, i have never tried that.. did it now. imo dof does render to the info channel passes too (as it should); what i also noticed is, that you will need to turn on rendering with alpha channel (in the kernel settings), if you have objects in front of "nothing", otherwise you will get sharp edges between the blurred parts and the background, what is most probably unwanted...

Sometimes D|S crashed by GPE in plordazs.dll

Some scene file cause GPE in plordazs.dll below.
"DAZStudio.exe caused ACCESS_VIOLATION in module "C:\Program Files\DAZ 3D\DAZStudio4\plugins\OctaneRender\plordazs.dll" at 0033:0000000010D96DFD, DzMatrix3::operator float * __ptr64()+1830549 byte(s)"

When I re-load the same scene file , sometimes cause GPE, sometimes complete to load.
What's happen in the world?

Error log at DAZStudio_error_report_OcDSCrash.zip on
https://skydrive.live.com/#cid=9E5F8EE5 ... A682%21174

TakashiKurashima wrote:Sometimes D|S crashed by GPE in plordazs.dll

from the log file i see one problem:
WARNING: general\dzscene.cpp(1530): Error in DzScene::clear()
this means, that an error happens, whenever DS tries to clear the scene (whether if something new gets loaded, or if you just call "new" from the file menu). this will in consequence cause the plugin's own clear routine not to run, and thus old (orphaned) data remains, data gets mixed, mismatched and is no longer valid. to me this looks like the error happens in DS itself (at least it reports a file from the DS code); to verify that: can you please turn the plugin off (main menu > help > about installed plugins > untick the octanerender plugin & restart), then do some usual loading/new/reloead/... and send me the log file agai. thanks!