Cannot rotate (ATP) asset when set to Collision Excact. and text error


#1

I wanted to rotate something. I did what i awlays did. except the default you get for collision -> excact. so i did choice that. It did not rotate ! after some puzzling i found that the excact collision mode is disable rotation !

I just noticed with the screen paste that it’s possible reported in thats creen. but it’s a tiny text ! and B it’s not complete !


#2

@Richardus.Raymaker on the latest dev build, 5324, i’m able to import an asset from my ATP w/ exact collisions and rotate it as expected. i’m able to change collision mode to one hull, hull per submesh, etc and it rotates as expected at each. could be a bug from an earlier build. if you don’t mind trying your asset w/ the most recent dev build http://highfidelity.io/dev-download , that would be helpful.

could you tell more about your setup? how are you rotating (rotation property, angular velocity, etc). what model are you using? are you on your localhost or another domain?

re: the message – bummer that it gets cut off; what’s your screen resolution / os-level font size settings / size of the window?? it should appear all the time, if it doesn’t we need to fix it. it should look like this


#3

I tried to rotate with angulair velocity. and it’s not working with Automatic collisions set to Excact - All polytypes. Started interface.exeSaem problem, starting interface.exe = crash. build 5312.


#4

angular velocity won’t work because that’s a dynamic property. static meshes can’t be dynamic. sorry you couldn’t see that in the error message. perhaps we should also add an error message when you try to edit a dynamic property for a static thing. that ux could be better.


#5

That’s something i figured out when i where writing the topic. but it neve rtold me because that tiny message dropped out of the box.


#6

yeah i’m down to fix the message – any hints to your setup as to why that might be? i haven’t done much with those QML popovers but i can take a look.


#7

That window is not QML right now. my windows desktop is set to 125dpi. sadly it’s not making font’s bigger in the QT windows.


#8

so does 125 dpi mean that by default, things are 25% bigger? i’ve never messed with that. if so, should we make that box fit 125dpi? 150? ty


#9

How the technologie works in windows am not complete sure. i just need 125% to keep things in windows readable on 1920x1080 27" screen.

At this moment i think high fidelity is ignoring the windows dpi setting complete. unless QML use it. But i think not.

Best solution would to give like you have in blender just a DPI slider for high fidelity that works indepent from windows. But i think that slider also only need to work in desktop mode. In HMD things look bigger with font.

Not something small to change right now. But i think high fidelity also better not wait years with it to implement.

Note that so far i know the way dpi works is changed between windows 7 and 10


#10

Both Windows and OS X have methods that apps can use to determine the size of the viewport and the scaling factor for rendered text. They even have methods and change-events that let the app preflight the size of text to be rendered. All that logic is there to permit apps to reformat to different geometries, window sizes on the fly. This was added specifically to Windows years ago in preparation for dynamic size changes that would take place when moving windows/viewports between monitors, between local and remote sessions, and also in preparation of moving things between devices, such as a computer monitor and your Windows mobile phone, or to the HoloLens spatial planes.

Apps that do not take into account that dynamism run the risk of having their text or other graphic elements get clipped.