Jump to content

CIGI CelestialControl overrides master and slave render_exposure value


photo

Recommended Posts

Posted

Hi,

The configuration of master+slaves is at startup:

  • master: render_exposure=0.5, render_exposure_mode=2
  • OTW slaves: render_exposure=1.2, render_exposure_mode=1
  • Sensor slaves: render_exposure=0.5, render_exposure_mode=2

This setup is made so sensors and master are auto adapting exposure, but the OTW have a fixed exposure calibrated for our environment.

The probleme: as soon as a CIGI CelestialControl is received, ALL slaves revert to render_exposure = 0.5, making the OTW very dark (exposure_mode is not changed).

Is this expected? How can I avoid this?

What is the preferred way if I want OTW to have fixed exposure (with a specific, configurable value), while still having other slaves with an auto exposure?

Thanks!

 

Posted

Hello! 

Syncker synchronizes basic render settings between all machines. Including render_exposure.

Unfortunately there is no way to disable synchronization of one parameter - only complete synchronization of render settings via slave->setSkipFlags(Slave::SKIP_FLAGS::RENDER) but it will lead to problems in weather synchronization: render_environment_presets are synchronized in the same block.

so in your case I can only suggest workaround: set the exposure in each frame - this function is very cheap and should not affect performance.

int AppSystemLogic::postUpdate()
{
	//...
	if (is_OTW_slave)
		Render::setExposure(1.2);
	//...
}

 

Posted

Understood, but in this case, it's not clear why render_exposure_mode is not synchronized too, for example. Can we have an exhaustive list of the actually synched parameters please?

As a suggestion, just like we have the possibility to select the post effect filter in a view in the xml, it would be great to be able to also set the other render parameters.

 

Posted

Because, in order to optimize the serialization of render settings, we only synchronize frequently changed parameters, assuming that they can change at runtime.

Changing the exposure_mode is not expected in every frame, so we do not synchronize it. Moreover, we recommend disabling autoexposure when you are using a multiple-projector system.

Here is all render parameters which are synchronized:

// distance parameters
DistanceScale
FieldDistance
LightDistance
DecalDistance
ObjectDistance
ShadowDistance
ReflectionDistance

// stereo parameters
StereoDistance
StereoRadius
StereoOffset

// animation parameters
AnimationStem
AnimationLeaf
AnimationScale
AnimationWind
AnimationTime

// environment presets
Intensity
ScatteringBaseLUTName
ScatteringMieLUTName
ScatteringLightColorLUTName
TextureName
TextureColor
HazeColor
HazeMaxDistance
HazeDensity
HazePhysicalStartHeight
HazePhysicalHalfVisibilityDistance
HazePhysicalHalfFalloffHeight
HazePhysicalSunLightIntensity
HazePhysicalSunColorSaturation
EnvironmentHazeMode

// SSAO
SSAOIntensity

// refraction
RefractionDispersion

// motion blur
MotionBlurVelocityScale
MotionBlurMaxVelocity

// screen-space shadow shafts
ScreenSpaceShadowShaftsMode
ScreenSpaceShadowShaftsResolution
ScreenSpaceShadowShaftsQuality
ScreenSpaceShadowShaftsLength

// depth of field post-processing
DOFFocalDistance
DOFChromaticAberration
DOFBlur
DOFFarDistance
DOFFarFocalOffset
DOFNearDistance
DOFNearFocalOffset

// camera effects post-processing
CameraEffectsThreshold
DirtTextureName
DirtScale

// exposure post-processing
Exposure
ExposureAdaptation
ExposureMinLuminance
ExposureMaxLuminance

// filmic post processing
FilmicShoulderScale
FilmicLinearScale
FilmicLinearAngle
FilmicToeScale
FilmicToeNumerator
FilmicToeDenominator
FilmicWhiteLevel

// cross post processing
CrossColor
CrossScale
CrossShafts
CrossLength
CrossAngle
CrossThreshold

// lens post processing
LensColor
LensScale
LensLength
LensRadius
LensThreshold
LensDispersion

// color post-processing
ColorCorrectionBrightness
ColorCorrectionContrast
ColorCorrectionGamma
ColorCorrectionWhite
ColorCorrectionRamp

// bloom
BloomScale
BloomPower

// fade post-processing
FadeColor

// clouds
CloudsLightingQuality
CloudsLightingTraceLength
CloudsLightingConeRadius
CloudsDynamicCoverageArea
CloudsDynamicCoverageResolution
CloudsInterleavedRendering
CloudsDownsamplingRendering
CloudsSamplingQuality
CloudsTransparentOrder

  • Like 1
Posted
Quote

As a suggestion, just like we have the possibility to select the post effect filter in a view in the xml, it would be great to be able to also set the other render parameters.

I didn't quite understand which render parameters you are referring to. Please tell us more details about task you are trying to solve. 

We are planning to change our approach to rendering parameter serialization in the near future, so it is important to understand your needs.

Posted

Thank you @cash-metall for this thorough listing. In essence, we have a single CIGI host that sends messages to the IG master which then has multiple slaves with different role.

  • the master itself displays view 0 as a spectator view or a 3rd person view of the helicopter, with cinematic effects (glow, lens flares, eye adaptation, etc)
  • the dome slaves displays view 1 as an OTW view, with no cinematic effect, no WB, no lens flares, no eye adaptation, no motion blur, etc
  • the sensors slaves display view 2+ as different sensors, with different effects depending on the sensor (WB, adaption, blur, noise, low resolution, etc)

Up until recently, all views had the same settings (ie the OTW settings) except for post-filter; but we recently had a request to had more "realist/cinematic" effect depending on the view type. And the master view is the most viewed one (as it is in the control room) and VIPs love to see cinematic effects :-)

To sum up, the current render settings are dispatched among the world definition, the render settings, the view post_filter. It would be great to be able to set all these in a dedicated "RenderFilter" object which could be attached to a view. Hope this makes sense!

Posted

Thanks for the explanation! I understood your task.
Indeed, it is now impossible to set different Render Settings for different viewports. Looks like a very useful setting.

As a temprorary workaround you can do this with other basematerial and UnigineScript inside.
File render_test.basemat there is an example of how to change some render settings from postmaterial. (but in this case, not all settings can change correctly due to injection into the render)

just copy file to data and specify in ig_config

<view_type type="1" post_materials="Unigine::post_sensor_heat,render_test"/>

 

  • Like 1
×
×
  • Create New...