I have a scene like two street lights (area lights) illuminating a flag pole in between them. If I render the scene once for each scene and sum the result, I get less contrast in each shadow than if I render the scene with both lights on together. I export the scenes as 16bit PNG. The signal is <1 everywhere with both lights on, and I don't normalize. Background is set to black.
Should summing the scenes with separate light sources give same result as rendering the scene once with both light sources? I have set Display_Gamma=1.0 and assumed_gamma 1.0
Some info on the scene (I can post an example pov ray file necessary):
The floor material is:
pigment { color rgbft<1.0,1.0,1.0,0.0,0.0> }
finish {ambient 0 diffuse albedo 1.}
The flag pole is:
texture { pigment {color Black }}
The light sources are like:
color rgb<0.125,0.125,0.125>
area_light <5, 0, 0>, <0, 0, 5>, 5, 5
adaptive 5
circular
OK, I also had to set File_Gamma=1.0
So to keep linear intensity units throughout, set the global option: assumed_gamma 1.0 and in the rendering command, include the parameters: File_Gamma=1.0 and Display_Gamma=1.0
All three gammas need to be 1.0 if you want to measure shadow contrast in linear units.
Related
I've tried modifying the FetchPickAndPlace-v1 OpenAI environment to replace the cube with a pair of scissors. Everything works perfectly except for the fact that my custom mesh seems to jitter a few millimeters in and out of the table every few time steps. I've included a picture mid-jitter below:
As you can see, the scissors are caught mid-way through the surface of the table. How can I prevent this? All I've done is switch out the code for the cube in pick_and_place.xml with the asset related to the scissor mesh. Here's the code of interest:
<body name="object0" pos="0.0 0.0 0.0">
<joint name="object0:joint" type="free" damping="0.01"></joint>
<geom size="0.025 0.025 0.025" mesh="tool0:scissors" condim="3" name="object0" material="tool_mat" class="tool0:matte" mass="2"></geom>
<site name="object0" pos="0 0 0" size="0.02 0.02 0.02" rgba="1 0 0 1" type="sphere"></site>
</body>
I've tried playing around with the coordinates of the position and geometry but to no avail. Any tips? Replacing mesh="tool0:scissors" with type="box" gets rid of the problem entirely but I'm back to square one.
As suggested by Emo Todorov in the MuJoCo forums:
Replace the ground box with a plane and
use MuJoCo 2.0. The latest version of the collision detector
generates multiple contacts between a mesh and a plane, which
results in more stable simulation. But this only works for
plane-mesh, not for box-mesh.
The better solution is to break the mesh into several meshes, and include them as multiple geoms in the same body. Then MuJoCo will construct the convex hull of each sub-mesh, resulting in multiple contact points (even without the special plane mechanism mentioned above) and furthermore it will be a better approximation to the actual object geometry.
I'm using the Cesium library to simulate the satellite motion. This code is used to show the path:
path:{
leadTime:data.data_list[0].period/2,
trailTime:data.data_list[0].period/2,
width:1.5,
material: color
}
Is there a way to make the trailing path thinner?
As an example, the SpaceX video: http://youtu.be/rQEqKZ7CJlk?t=47m40s
Couple of comments here. First, with a width of only 1.5, altering the width is likely not the effect you want. Try using a solid color vs a faded color, such as by changing the alpha value. This should be more similar to what you're seeing in that video link.
But, currently Cesium does not support separate path materials for lead and trail times. If you really need both lead and trail paths shown with different colors/widths/etc, you have to insert a duplicate entity in your CZML (whose position can just be a reference to the primary entity position), such that one entity can have only a leadtime and the other has only a trailtime, and they use different path materials.
But if you have a satellite in a stable orbit, you there's a different approach you can take, because the thing keeps circling around the same path. You can use the StripeMaterial to make the orbit line fade from one side to the other.
Here's a live demo that loads simple.czml and replaces the Molniya's yellow orbit with a faded line. The solid part is the most recent trail of the satellite, and the faded part is much further back but serves to show where the satellite is headed next.
Cesium.Camera.DEFAULT_VIEW_FACTOR = 5.5;
var viewer = new Cesium.Viewer('cesiumContainer', {
shouldAnimate : true
});
Cesium.CzmlDataSource.load('../../../../Apps/SampleData/simple.czml').then(function(dataSource) {
viewer.dataSources.add(dataSource);
viewer.camera.flyHome(0);
viewer.clock.multiplier = 1800;
var entity = dataSource.entities.getById('Satellite/Molniya_1-92');
var fadedLine = new Cesium.StripeMaterialProperty({
// The newest part of the line is bright yellow.
evenColor: Cesium.Color.YELLOW,
// The oldest part of the line is yellow with a low alpha value.
oddColor: Cesium.Color.YELLOW.withAlpha(0.2),
repeat: 1,
offset: 0.25,
orientation: Cesium.StripeOrientation.VERTICAL
});
entity.path.material = fadedLine;
entity.path.leadTime = new Cesium.ConstantProperty(0);
entity.path.trailTime = new Cesium.ConstantProperty(3600 * 12);
});
Here you can play with the color, of course, but I would recommend keeping the same base color for even and odd. The withAlpha value of 0.2 on the oddColor here controls how faded the line gets, range is 0 to 1. The offsetvalue here can also be tweaked, to control the placement of the fade range. leadTime should be zero, and trailTime should be the orbit's period.
When running the following code, "-2" is being traced and I am wrecking my head trying to understand why.
var bmd:BitmapData = new BitmapData(1,1,true,0xFFFFFFFF);
bmd.setPixel32(0,0, 0x32FF6B45);
trace(0x32FF6B45-bmd.getPixel32(0,0));
As far as I can tell, it should trace 0. 0x32FF6B45 is initially assigned to the pixel at coords 0,0. That value should be returned in bmd.getPixel32(0,0) and then, when it's subtracted from 0x32FF6B45, it should result in 0. Why the heck am I getting -2?
EDIT:
I've traced out the values individually and it makes sense that the operation in the trace above results in -2 because tracing out 0x32FF6B45 results in 855599941 and tracing out bmd.getPixel32(0,0) results in 855599943. The question now is why the heck are those values different? Whey doesn't bmd.getPixel32(0,0) also trace out 855599941?
I have the same problem, and I believe it is related to premultiplied alpha, as described here. In my code I was setting a pixel to 0xa08800ff and getting back 0xa08700ff. If you need alphas other than 0xff, then unfortunately it may be necessary to simultaneously store all your pixel values in a separate data structure too.
That is expected.
getPixel
This will return a value: #RRGGBB (rgb / red, green, blue)
getPixel32
This will return a value: #AARRGGBB (argb / alpha, red, green, blue)
Example:
trace('test 0x32FF6B45: '+0x32FF6B45);
var bmd:BitmapData = new BitmapData(1,1,true,0xFFFFFFFF);
trace('setting 0,0 to 0x32FF6B45');
bmd.setPixel32(0,0, 0x32FF6B45);
var color:* = bmd.getPixel32(0,0)
trace('0,0: '+color);
trace(color-bmd.getPixel32(0,0));
Results:
test 0x32FF6B45: 855599941
setting 0,0 to 0x32FF6B45
0,0: 855599943
0
From what I can tell, you're using a color that is out-of-bounds to Flash. I'm not sure of the color range, but I know in previous experiences when taking photoshop elements with many colors, sometimes objects failed to import because the color value was out of bounds.
#Jari is also correct about the transparency.
The program will show the student a line graph. The student will have to recreate that line graph by moving a character away from or toward a motion detector using the arrow keys, creating a distance-time plot. I can capture the data points that the program generates when drawing its graph. I can also capture the data points gnerated by the student. How can I compare the two graphs while allowing for some tolerance on the student's part? Should I try to detect incorrect graphs as they are being drawn or after all data points are recorded? While some of the graphs will be linear and easy to compare others will be piecewise functions with positive, negative, and zero slopes at random intervals.
Thanks!
Does the order in which the graph lines are drawn matter ?
You could record the points with a certain threshold into an Array/Vector and compare.
A quick'n'dirty way would be using 2 binary(monochrome, just black and white) images:
One image will be a 'print screen'(BitmapData.draw()) of the graph(e.g. black on white)
The other image will be a white(blank) BitmapData that you'll use to write black pixels
where the user/student draws(has the mouse while it's pressed).
e.g.
userBitmapData.setPixel(mouseX,mouseY,0x000000);
When the drawing is complete(either the mouse is released or whatever rule you set),
you run a function that checks how much black pixels from the source(original graph) image
are matched in the destination(user graph) image.
Either you create a BitmapData containing the other two bitmaps blended on Difference mode, so anything that isn't black is not a match, or just loop through all the pixels once and manually check if the pixels match. Note that this relies on the fact that dimensions(width,height) of the two images are the same.
Here's a bit of code to illustrate this:
function compare(source:BitmapData,destination:BitmapData,threshold:Number):Boolean{
var commonPixels:Number = 0, totalPixels:Number = 0;
for(var j:int = 0 ; j < source.height ; j++){
for(var i:int = 0 ; i < source.width; i++){
pixels++;
if(source.getPixel(i,j) == destination.getPixel(i,j)) commonPixels++;
}
}
trace('matching: ' + (commonPixels/pixels * 100) + ' % ');//delete this line,just testing
if(commonPixels/pixels >= threshold) return true;
else return false;
}
//usage:
trace('is the graph correct ?: ' + compare(graphBitmapData,userBitmapData,0.7));
The Vector/Array version would be similar, but there would be no visual cues. Depending on your setup, you might want to test which would work best for you: BitmapData takes more memory than Arrays, but you can easily create a Bitmap, add it to the display list and check if looks right, etc.
If speed is an issue:
using Vector. instead of Array might be faster
looping in reverse(highest number to 0, decrementing) also should speed up things a bit
you probably get away with one loop instead of two
e.g.
var pixels:int = source.width * source.height;
for(pixels; pixels >=0; pixels--)
HTH
I have a pygame.Timer running in my game calling a draw function 32 times/second. The drawing method gets positions from all elements on my screen and blits them accordingly. However, I want the main character to walk around slower than other objects move.
Should I set up a timer specifically for it or should I just blit the same frames several times? Is there any better way to do it? A push in the right direction would be awesome :)
(If anyone's interested, here is the code that currently controls what frames to send to the drawing: http://github.com/kallepersson/subterranean-ng/blob/master/Player.py#L88)
Your walk cycle frame (like all motion) should be a function of absolute time, not of frame count. e.g.:
def walk_frame(millis, frames_per_second, framecount, start_millis=0):
millis_per_frame = 1000 / frames_per_second
elapsed_millis = millis - start_millis
total_frames = elapsed_millis / millis_per_frame
return total_frames % framecount