I'm studying VRML as a beginner. I have a problem with TimeSensor that need help. This is my source code
DEF time TimeSensor
{
loop TRUE
cycleInterval 2
}
DEF C11 Transform
{
translation -3 0 0
children
[
Shape
{
geometry Sphere
{
radius 0.5
}
appearance Appearance
{
material Material
{
diffuseColor 0 0 0
specularColor .29 .3 .29
shininess .08
ambientIntensity 0
transparency 0.0
}
}
}
DEF moveC11 PositionInterpolator
{
key [0 1]
keyValue [-3 0 0,3 3 0]
}
]
}
ROUTE time.fraction_changed TO moveC11.set_fraction
ROUTE moveC11.value_changed TO C11.translation
When I view in browser, the sphere moves from coordinate -3 0 0 to 3 3 0 and repeat.I want it moves only 1 time. The sphere stop at coordinate 3 3 0. How can I do it?
Thank you for helping me!
VRML concept of TimeSensor is other than to stop an infinite loop
A reverse logic works:
Modify DEF time TimeSensor { loop FALSE } to avoid uncontrollable infinite loop.
Send an event set_startTime with the current time to the TimeSensor.
The problem with this approach might be how to compute the absolute current time in seconds since 1970-01-01 00:00:00.
Fortunately all sensors in VRML generate events which output a time value when they become active.
So basically all you have to do is to ROUTE the event generated by the sensor when it becomes active to the eventIn of the TimeSensor set_startTime.
Related
Consider a 2D square tiled grid (chess board like) which contains conveyor belt like structures that can curve and move game pieces around.
I need to calculate the turn movement (TURN_LEFT, TURN_RIGHT or STAY), depending on
the direction from which a piece moves onto the field
the direction from which the underlying belt exits the field
Example:
1 2
1 |>X>|>v |
2 | | v |
The belt makes a RIGHT turn. As such, the result of calcTurn(LEFT, DOWN) should be TURN_RIGHT. Meaning the X game piece will be rotated 90° right when it moves over the curve at (1,2).
I already implemented a function but it only works on some of my test cases.
enum class Direction {
NONE,
UP,
RIGHT,
DOWN,
LEFT;
fun isOpposite(other: Direction) = this == UP && other == DOWN
|| this == DOWN && other == UP
|| this == LEFT && other == RIGHT
|| this == RIGHT && other == LEFT
}
data class Vec2(val x: Float, val y: Float)
fun Direction.toVec2() = when (this) {
Direction.NONE -> Vec2(0f, 0f)
Direction.UP -> Vec2(0f, 1f)
Direction.RIGHT -> Vec2(1f, 0f)
Direction.DOWN -> Vec2(0f, -1f)
Direction.LEFT -> Vec2(-1f, 0f)
}
fun getTurnMovement(incomingDirection: Direction, outgoingDirection: Direction): Movement {
if (incomingDirection.isOpposite(outgoingDirection) || incomingDirection == outgoingDirection) {
return Movement.STAY
}
val incVec = incomingDirection.toVec2()
val outVec = outgoingDirection.toVec2()
val angle = atan2(
incVec.x * outVec.x - incVec.y * outVec.y,
incVec.x * outVec.x + incVec.y * outVec.y
)
return when {
angle < 0 -> Movement.TURN_RIGHT
angle > 0 -> Movement.TURN_LEFT
else -> Movement.STAY
}
}
I can't quite figure out what's going wrong here, especially not because some test cases work (like DOWN+LEFT=TURN_LEFT) but others don't (like DOWN+RIGHT=STAY instead of TURN_LEFT)
You're trying to calculate the angle between two two-dimensional vectors, but are doing so incorrectly.
Mathematically, given two vectors (x1,y1) and (x2,y2), the angle between them is the angle of the second to the x-axis minus the angle of the first to the x-axis. In equation form: arctan(y2/x2) - arctan(y1/x1).
Translating that to Kotlin, you should instead use:
val angle = atan2(outVec.y, outVec.x) - atan2(incVec.y, incVec.x)
I'd note that you could achieve also your overall goal by just delineating the cases in a when statement as you only have a small number of possible directions, but perhaps you want a more general solution.
It's not answering your question of why your code isn't working, but here's another general approach you could use for wrapping ordered data like this:
enum class Direction {
UP, RIGHT, DOWN, LEFT;
companion object {
// storing thing means you only need to generate the array once
private val directions = values()
private fun getPositionWrapped(pos: Int) = directions[(pos).mod(directions.size)]
}
// using getters here as a general example
val toLeft get() = getPositionWrapped(ordinal - 1)
val toRight get() = getPositionWrapped(ordinal + 1)
val opposite get() = getPositionWrapped(ordinal + 2)
}
It's taking advantage of the fact enums are ordered, with an ordinal property to pull out the position of a particular constant. It also uses the (x).mod(y) trick where if x is negative, putting it in parentheses makes it wrap around
x| 6 5 4 3 2 1 0 -1 -2 -3 -4 -5
mod 4| 2 1 0 3 2 1 0 3 2 1 0 3
which makes it easy to grab the next or previous (or however far you want to jump) index, acting like a circular array.
Since you have a NONE value in your example (which obviously doesn't fit into this pattern) I'd probably represent that with a null Direction? instead, since it's more of a lack of a value than an actual type of direction. Depends what you're doing of course!
When we subscribe ScrollView.onScrollEndDrag it gives us nativeEvent. Which has velocity in it. The following shows how it's defined in typescript.
export interface NativeScrollEvent {
contentInset: NativeScrollRectangle;
contentOffset: NativeScrollPoint;
contentSize: NativeScrollSize;
layoutMeasurement: NativeScrollSize;
velocity?: NativeScrollVelocity;
zoomScale: number;
/**
* #platform ios
*/
targetContentOffset?: NativeScrollPoint;
}
In velocity, we have x and y velocity as a number which is a negative or positive number as it decreases or increases.
I want to know what does that 1 exactly means like 1 pixel per second or ...
Does someone know how to do higher roots (cube roots, 4th roots, etc) in groff eqn? Been searching around the docs and cant seem to find the answer
In simple cases you can use a subscripted number before the root sign:
"" sup 3 sqrt x
but this does not look too good depending on the equation:
1 over { "" sup 3 { sqrt {ax sup 2 +bx+c} } }
An alternative is to use left-justified pile, which also has a large gap:
1 over { lpile { { size -8 3 } above { sqrt {ax sup 2 +bx+c} } } }
so often the best is to use the eqn local motion commands, up, back, size to play with the position to get the wanted result:
1 over { { up 90 size -8 3 } back 30 { sqrt {ax sup 2 +bx+c} } }
I would recommend using eqn macros like this
.EQ
define exp % "" sup fwd 30 %
define cube % "" sup fwd 30 3 sqrt %
define root % { "" sup fwd 30 $1 sqrt $2 } %
exp 3 sqrt 11
cube 11
root(3,11)
.EN
I'm using the Core Location Framework from apple.
I need to know if CLLocationDirection (course of the GPS) is the way to determine whether the moving vehicle is turning left or right or going straight ? If so, how ?
If not, is there another feature of the framework better suited to identifying turns?
Any kind of help is appreciated.
As I said in the comments CLLocationDirection can work for this if you use it over time.
That said, it's not without issues. newHeading - oldHeading will be positive for right turns and negative for left turns but only when the two headings don't find them selves on either side of north.
Going from 355 to 5 should give a +10Deg (right turn). So you have a corner case to resolve.
The basic assumption you have to make is that the turn happened over the smaller angle. Which will be true if the data collection rate is reasonable and the car isn't tumbling over a cliff. If it is I doubt the passengers will care if the GPS gets confused.
objective-c might have a more elegant way to calculate this but my java polluted brain see's it as:
// Some test data
// deltaH newH oldH expected
// -350 = 5 - 355 should return +10
// -355 = 0 - 355 should return +5
// 5 = 5 - 0 should return +5
// -10 = 5 - 15 should return -10
// 10 = 15 - 5 should return 10
// -181 = 0 - 181 should return 179
// 181 = 181 - 0 should return -179
//
int deltaH = newH - oldH;
//Ensure deltaH takes the shortest path from oldH to newH
if ( -180 < deltaH && deltaH < 180 ) {
return deltaH;
} else if (deltaH <= -180) {
return deltaH + 360;
} else if (deltaH >= 180) {
return deltaH - 360;
} else {
throw new AssertionError("Logic error");
}
I'm sure there's a way translate that into objective-c.
Another issue is precision loss. If CLLocationDirection is calculated from a more raw data source, say GPS positional data, then it is very likely that whatever calculates CLLocationDirection is lossy. Meaning it should be possible to get more accurate results by going back to the raw data and calculating turn direction from that. When calculating derivatives this stuff becomes important.
While reading about the threads in SystemC, it is said that while(true) loop must be used inside the functions. Why is it so?
Can you please see the example code given below and explain why the while loop is used for threads and wait() command is used along with the loop:
1 //-----------------------------------------------------
2 // This is my second Systemc Example
3 // Design Name : first_counter
4 // File Name : first_counter.cpp
5 // Function : This is a 4 bit up-counter with
6 // Synchronous active high reset and
7 // with active high enable signal
8 //-----------------------------------------------------
9 #include "systemc.h"
10
11 SC_MODULE (first_counter) {
12 sc_in_clk clock ; // Clock input of the design
13 sc_in<bool> reset ; // active high, synchronous Reset input
14 sc_in<bool> enable; // Active high enable signal for counter
15 sc_out<sc_uint<4> > counter_out; // 4 bit vector output of the counter
16
17 //------------Local Variables Here---------------------
18 sc_uint<4> count;
19
20 //------------Code Starts Here-------------------------
21 // Below function implements actual counter logic
22 void incr_count () {
23 // For threads, we need to have while true loop
24 while (true) {
25 // Wait for the event in sensitivity list to occure
26 // In this example - positive edge of clock
27 wait();
28 if (reset.read() == 1) {
29 count = 0;
30 counter_out.write(count);
31 // If enable is active, then we increment the counter
32 } else if (enable.read() == 1) {
33 count = count + 1;
34 counter_out.write(count);
35 }
36 }
37 } // End of function incr_count
38
39 // Below functions prints value of count when ever it changes
40 void print_count () {
41 while (true) {
42 wait();
43 cout<<"#" << sc_time_stamp() <<
44 " :: Counter Value "<<counter_out.read()<<endl;
45 }
46 }
47
48 // Constructor for the counter
49 // Since this counter is a positive edge trigged one,
50 // We trigger the below block with respect to positive
51 // edge of the clock
52 SC_CTOR(first_counter) {
53 // Edge sensitive to clock
54 SC_THREAD(incr_count);
55 sensitive << clock.pos();
56 // Level Sensitive to change in counter output
57 SC_THREAD(print_count);
58 sensitive << counter_out;
59 } // End of Constructor
60
61 }; // End of Module counter
SC_THREAD or SC_CTHREAD should have infinite loop to keep the thread not being terminated. If you don't put for(;;) or while(true) in the function body, when the execution reaches the end of function scope, the thread is terminated. In such case, your thread will never be waken up by the sensitive list for processing something. Or you can it transform to equivalent SC_METHOD, then you can have no infinite loop.
SystemC is using non-preemptive thread, so if you don't use wait() to wait for something listed in static or dynamic sensitive list to happen, it causes a infinite execution in your thread. And CPU execution of your process won't get out of the function scope. Such that SystemC kernel won't able to continue to process other methods/threads and events to continue the simulation. And in the event-based simulation, the thread should only be run when the specified condition (events in the sensitive list) occur. So the wait() function can wait until the next event occurs and hand over the CPU execution to other threads/methods and SystemC kernel. Next time the event occurs, for example the positive edge of clock, wait() statement will return and continue your process.
In your example, your program is waiting for clock's positive edge trigger to increase the counter's value by 1. So, if you don't put wait() in your code, then incr_count will always increase the counter's value infinitely no matter the clock's status, and it won't stop. By using wait(), your thread will be blocked and wait for next clock positive edge trigger.
while(true) --> makes thread infinite, so that it can keep executing when it gets context
wait() --> forces the thread to lose context and allows something else to be executed