Openscad : linear_extrude won't scale - openscad

This simple code :
linear_extrude(height = 10, scale =2) {
circle(r = 1);
}
create a cylinder instead of scaling the circle during the extrusion.
Result:

The code works fine with the latest release version (2015.03-2). I'd suggest to check the version of OpenSCAD you are running. It might be an old release which does not support the scale parameter.

Related

Image created upside down in Android

I am using the following code to export SceneCaptureComponent as a PNG image on the device and I am facing a weird issue.
On Windows and iOS everything works as expected.
On Android the image is upside down, like it is rotated by 180 degrees.
Any hints why?
bool UsaveJPG::SaveImage(class USceneCaptureComponent2D* Target, const FString ImagePath, const FLinearColor ClearColour)
{
FRenderTarget* RenderTarget = Target->TextureTarget->GameThread_GetRenderTargetResource();
if (RenderTarget == nullptr)
{
return false;
}
TArray<FColor> RawPixels;
// Format not supported - use PF_B8G8R8A8.
if (Target->TextureTarget->GetFormat() != PF_B8G8R8A8)
{
// TRACEWARN("Format not supported - use PF_B8G8R8A8.");
return false;
}
if (!RenderTarget->ReadPixels(RawPixels))
{
return false;
}
// Convert to FColor.
FColor ClearFColour = ClearColour.ToFColor(false); // FIXME - want sRGB or not?
for (auto& Pixel : RawPixels)
{
// Switch Red/Blue changes.
const uint8 PR = Pixel.R;
const uint8 PB = Pixel.B;
Pixel.R = PB;
Pixel.B = PR;
// Set alpha based on RGB values of ClearColour.
Pixel.A = ((Pixel.R == ClearFColour.R) && (Pixel.G == ClearFColour.G) && (Pixel.B == ClearFColour.B)) ? 0 : 255;
}
TSharedPtr<IImageWrapper> ImageWrapper = ImageWrapperModule.CreateImageWrapper(EImageFormat::PNG);
const int32 Width = Target->TextureTarget->SizeX;
const int32 Height = Target->TextureTarget->SizeY;
if (ImageWrapper.IsValid() && ImageWrapper->SetRaw(&RawPixels[0], RawPixels.Num() * sizeof(FColor), Width, Height, ERGBFormat::RGBA, 8))
{
FFileHelper::SaveArrayToFile(ImageWrapper->GetCompressed(), *ImagePath);
return true;
}
return false;
}
It seems as if you aren't the only one having this issue.
Questions with answers (bolding to pop out answer section):
"I believe the editor mobile preview provides "correct" results, while the mobile device produces upside down results. I ran into this issue when creating a post process volume to simulate a camera partially submerged in water with mathematically calculated wave displacement. I can convert the screen position to world position using a custom material node with the code: float2 ViewPos = (ScreenPos.xy - View.ScreenPositionScaleBias.wz) / View.ScreenPositionScaleBias.xy * 10; float4 Pos = mul(float4(ViewPos, 10, 1), [Link Removed]); return Pos.xyz / Pos.w; This works as expected in the editor mobile preview, but the results are weirdly flipped around when launching to a mobile device. Manually inverting the Y-coordinate of the UV by subtracting the Y-component from 1 will correct the ViewportUV output, but the world space calculation still doesn't work (probably because [Link Removed] and [Link Removed]need to also be inverted). Strangely, if I feed the inverted UV coordinates into SceneTexture:PostProcessInput0, the entire scene flips upside down when running on a mobile device. This means that the ScreenPosition's ViewportUV is not the same as the SceneTexture UV. As a result, any post process effects that rely on the ViewportUV do not work correctly when running on mobile devices."
https://unreal-engine-issues.herokuapp.com/issue/UE-63442
I'm having trouble getting the tilt function to work with my Android phone. It seems that the tilt values are upside down because when I hold the phone flat on the table with the screen up, the tilt values snap from values like x=-3,y=0,z=-3 to z=3,y=0,z=3. When I hold the phone up with the screen facing down, the values are much closer to 0 all round.
Response:
tilt Y is always zero on android devices. but works fine on IOS
I think nobody has reported it as bug yet :) you do it
https://answers.unrealengine.com/questions/467434/tilt-vector-values-on-android-seem-to-be-upside-do.html?sort=oldest
I'm not an Unreal dev, but you might have to put in a condition for Android to invert the image for yourself. I've done that kind of thing before (think cross browser compatibility). It's always a PITA and bloats the code for a stupid "reason", but sometimes it's what you have to do. Maybe Unreal will release a patch for it, but not likely, since any other devs who've already accepted and accounted for this issue will now have to fix their "fixed" code. It may just have to be something you live with, unfortunately.
With reading this, it just sounds like the different OSs decided on different corners for the origin of the "graph" that is the screen. Win and iOS seem to have chosen the same corner, while Android chose differently. I've done similar things in programming as well as for CNC machines. You may be able to choose your "world origin" and orientation in setting.
Open the Find in Blueprints menu item.
Search for Debug Draw World Origin. In the results, double-click the Debug Draw World Origin function.
https://docs.unrealengine.com/en-US/Platforms/AR/HandheldAR/ARHowToShowWorldOrigin/index.html
There's not much out there that I can decipher being relevant, but searching for "android unreal world origin" gets a few results that might help. And adding "orientation" gets some different, possibly relevant, results.

Convert left-handed Y-up (e.g. Unity) coordinates&rotations to right-handed Z-up (3DS Max)

We develop an application that uses models exported as an fbx from max in unity (seems to work), changes them and then communicates the changes back to 3DSMax for a clean render.
We rotate the model pivot in max in such a way in max that it is shown correctly in Unity after the export.
What we got so far:
Position:
x(max) = x(unity)
y(max) = z(unity)
z(max) = y(unity)
Rotation:
x(max) = x(unity)
y(max) = -y(unity)
z(max) = z(unity)
Simple rotations seem to work, complex do not. I suspect we did not properly take the mirroring when going from left handed to right handed or the different rotation multiplication order into account. How is the mapping done correctly?
There is a related question with no answers:
Unity rotation convertion
The issue was the different rotation order of Unity (XYZ) and Max (ZYX). That explains that single rotations work but not complex ones. If you do the transformation in the question above and then just do each rotation in the same order consecutively in Unity, it works.

In Scala, is it possible to use Plotly's Scatter3d?

My aim is to display points in a 3D space/chart/graph. In python, it seems to be possible : https://plot.ly/python/3d-scatter-plots/
But in Scala, I didn't find this object/class/trait :
The Web site speaks only about surfaces : https://plot.ly/scala/
The Plotly's documentation doesn't contain Scatter3d but only Scatter, which doesn't seem to support 3D : https://asidatascience.github.io/scala-plotly-client/latest/api/#co.theasi.plotly.Scatter
The ThreeDPlot class seems impossible to display points in 3D without drawing surfaces : https://asidatascience.github.io/scala-plotly-client/latest/api/#co.theasi.plotly.ThreeDPlot, and the set of Z-coordinates is strange (e.g. Iterable[Iterable[Double]] instead of something easier, e.g. Iterable[Double])
The GitHub page's presentation use 3D points but display the only in a 2D space, by using only the X and Y coordinates : https://github.com/ASIDataScience/scala-plotly-client
Unfortunately the latest version does not support 3D scatter plots yet.
However I've forked the project and added basic support for 3D scatter plots.
Here is an example that can be run directly from the sbt console:
val (x,y,z) = (Vector(1.0, 3.0, 3.0),Vector(2.0, 5.0, 1.0),Vector(5.0, 7.0, -1.0))
val p = ThreeDPlot().withScatter3D(x,y,z,ScatterOptions().copy(mode = Seq(ScatterMode.Marker)));
draw(p, "hello-plotly");
I've also opened a pull request so that the commit gets reviewed and possibly merged also.
You may use matplotlib (most especially mplot3d)
Taking in consideration that matplotlib does not support natively Scala, you need to convert your scala data to matplotlib format before display and/or use this module which is:
The missing MatPlotLib for Scala + Spark
Regards

SKEmitterNode HSV range

While I usually prefer RGB color space over HSV, I'd like SKEmitterNode to emit particles with max saturation and value and have hue value to range across all colors. Is that possible?
I'm new to XCode, Swift and SpriteKit, and am unable to open .sks files due to a bug in XCode, so I don't know what can be done that way, but as far as I learned by looking through docs, the closest I can get is setting RGB range as in:
emitter.particleColorRedRange = 0.5;
emitter.particleColorGreenRange = 0.5;
emitter.particleColorBlueRange = 0.5;
Is there something like this:
emitter.particleColorHueRange = 0.5;
emitter.particleColorSaturationRange = 0.0;
emitter.particleColorValueRange = 0.0;
I could make a bunch of SKEmitterNode instances, with each of them having set specific UIColor, but that seems like very inefficient and ugly hack.
Thanks, Mirac7
SKEmitterNode does not provide an API for working within an HSV colorspace. One possible alternative would be to specify an explicit sequence of colors using the particleColorSequence property.

opengl renderer not working Intel HD graphics 2500

I have been unsuccessful trying to use the OpenGL driver with ILNumerics visualizations. I am trying to just do a basic visualization following Quick Start guide - every time I launch the application I get the error message "no compatible hardware accelerated driver could be found or activated" with error reported "Attempted to read or write protected memory. This is often an indication that other memory is corrupt". The graphics driver falls back to GDI which is really slow.
I have tried all of the suggested fixes for this problem. I installed the latest Intel HD graphics driver, and I ran OpenGL Extensions viewer which indicates that OpenGL 4.0 is supported. ILNumerics documentation indicates 3.1+ is required, which my system appears to support.
So I am at a loss here. Is there a way to use hardware rendering with this Intel card, or not?
I have also been trying to use the ILNumerics OpenGL driver but with an an Intel HD4000. I get the same error and the debug log shows that ILNumerics crashes with at the glDrawElements call.
I found a work around when initializing an ilPlotCube so that the OpenGL driver will not crash. I am using the Window Forms ilPanel control and ilNumerics 3.2.2.0 from NuGet.
In the ilPanel_load event create an ilPlotCube and set the x-axis scale to logarithmic. Add the plotcube to the scene.
Add an ilPoint element to the plotcube. I fill it with random data.
For me this runs and the plot control loads using the OpenGL driver without crashing.
void ilPanel1_Load(object sender, EventArgs e)
{
var pc = new ILPlotCube(twoDMode: false);
// Set an axis scale to logarithmic so the GL driver will not crash
pc.ScaleModes.XAxisScale = AxisScale.Logarithmic;
// Create a new scene
var scene = new ILScene();
scene.Add(pc);
this.ilPanel1.Scene = scene;
// Add points to the scene so the GL driver will not crash
this.AddPoints();
}
/// <summary>
/// Add an ILPoints object so GL driver will not crash
/// </summary>
private void AddPoints()
{
var pc = ilPanel1.Scene.First<ILPlotCube>();
ILArray<float> A = ILMath.tosingle(ILMath.rand(3, 1000));
var points = new ILPoints
{
Positions = A,
Colors = A,
Size = 2,
};
pc.Add(points);
this.points = points;
}
If the control loads successfully with the OpenGL driver then remove the points element from the scene. Set the axis scale as desired. Add another charting element which plots the actual thing you want to plot.
// Remove the ILPoints shape
if (this.points != null && ilPanel1.Scene.Contains(points))
{
ilPanel1.Scene.Remove(this.points);
this.points = null;
}
// Set the axis scale back to linear
var pcsm = ilPanel1.Scene.First<ILPlotCube>().ScaleModes;
pcsm.XAxisScale = AxisScale.Linear;
// Add actual plots here
Intel HD graphics often causes problems with OpenGL. You should file a bugreport on the Intel bugtracker and resort to a graphics card which does support OpenGL 3.1 - really.