So what have you learned from 660 Authoring tool?

Hey since it is just my first attempt to a teamwork programming project, also it is my first time to use an outer library. It was really tricky, but I really learned a lot.

Got to know how to compile an outer library using CMake on Windows Platform.

It is really important to read the instructions carefully first, be fully aware about the functions, requirements and limitations of the library to decide whether it is applicable. For example, CGAL requires each computed polygon is counter clockwise, which means some preconditions have to be made.

Compiling and debugging to details of the library can help understand how it works, but it is costly without a full understanding about the instructions.

For this modeling project, the curve editor framework using OpenGL output is really essential. Firstly it help test eligibility and functionality of the library in simple conditions. It also help when a specific and wired bug appears by creating the exact numerical environment.

BE CAREFUL about the whole developing process! Never do tons of coding without any output and debugging  like this time. It is lucky that I kept a relatively clear thought all through the construction of the project, but it is really DANGEROUS! It is very likely that millions of tiny bugs are hidden in the lines, which will take much more time to eliminate than the construction itself!
The right way: a little bit process->output->debug->success->a little more process.
Another right method I think is: construct simple situation->debug->success->add more complex conditions
So keep these micro circulations to build a project is most likely to be robust.

Make good use of Google to help clarify and solve problems with the library. See whether others met with similar tricks. Maybe there is no direct answer, other ppl's experiences can of course provide hints and inspirations for solutions, like the solution of "double" and "float" which took more than three days to figure out.

Got more about how C++ works, and also Maya plugin process, like get a 3D meshed model from a vector<vec3>. But still, my work is mostly concentrated on C++ programming. So I need more practice and understanding about Maya API!

Should be FULLY aware of the importance of Design Document. It should be written specifically and clearly to follow. Should also look back to it often during projection to keep close track of it. It is good to have brilliant ideas, but I guess it is not a good idea to forget about the initial targets.
Ask Dr. Lane about the significance of Design Document and its modification.

To be continued...

So We Get More!

So we've got further towards our final goal!
We have extended the construction of CSG from 2 silhouettes to 3!
In this step, for each cylinder's facet, we intersect it with the other silhouettes' cross shape polygon, and in doing so create the mesh for the final 3D model.


Come on, take a look at the output!

Cheers!

Authoring Tool Update: 416

Facet tmpFacet2(Intruder.Vertices);

in vector<Facet> Silhouette::Intersect(Silhouette Intruder)

coz intersection should be between base's facet and intruder's cross shape 

Authoring Tool Update: 415

plane equation implemented for each facet

carry on man
get some output next

Bubble Bomber Update : Version 15

Adding bubble expansion sink term Ea. It should be given by a simple mass balance removing the gas added to the discrete bubble from the dissolved gas in the local SPH particles, but what is MASS BALANCE?!!

Now just calculate it by a distance weight from the surrounding fluid particles to determine gas transfer to bubbles(threshold as 0.01), and increase the bubble  radius by an arbitrary constant of 0.10 * pcurr->gas_concentration * fac.

Parameters:

float mR = 100 * m_Param[SPH_SMOOTHRADIUS];

Vector3DF r ( p->pos.x - pcurr->pos.x, p->pos.y - pcurr->pos.y, p->pos.z - pcurr->pos.z );

double distance = r.Length();

double fac = (mR - distance) / mR;

if (fac < 1.0  && fac > 0.0 && pcurr->gas_concentration >= 0.01) {

//the default contribution is set up as 0.01

pcurr->gas_concentration -= 0.01 * fac;

p->gas_concentration += 0.01 * fac;

p->radius += 0.01 * fac;

//p->gas_concentration

So in this commitment I assumed the non strict law of gas transferring and bubble expansion(radius increases according to the distance weight of surrounding fluid particles and 0.10 * pcurr->gas_concentration * fac).

Should modify them after clarify the laws.

Bubble Bomber Update

Added bubble generator to all the boundary detections except for the ceiling

Added the condition p->pos.z <= 0.6 * max.z for each bubble generation except for z direction

Notes for Bubble Generator: Version 9

1. Added gas_concentration to struct Fluid, set up m_Pram [ GAS_CON ] as 0.15, the same in the form, initialize it in the function FluidSystem::AddPoint and AddPointReuse
2. Added an 1D array containing all the grids by the size of 1 in the container in the class FluidSystem, initialize it by the end of FluidSystem::AddVolume.
3. Added an bubble generator to the bottom of the container, controlled by two parameters:  GAS_LOSS(26) and BUB_GAS(27)
4. Resumed the Emit function back to the original status.
5. Changed MAX_PARAM to 30

Things to do:

1. Expanded the bottom to all of the boundaries
2. Implement the formula (8)

Q: Cannot generate bubbles in release mode???

Bubble Update

added scale to Point struct
added scale to Particle struct

something wired but helpful:
the three structures: Point, Particle and Fluid are independent, but share some basic elements at the head of each. it is kind of like Point is the base class of Particle, and Particle is the base class of Fluid. So each time the elements in Fluid are changed, after the pointer is converted to char* and then to Particle* or Point*, the couterpart will also be updated. I think the shared elements in the three structs must be totally the same, including sequence, so this is kind of dangerous, but the author seemed make use of this property.

anyway, after this, we can draw the bubble particle directly according to its scale, so we can see its expansion vividly. The threshold scale of bubble particle is (0.5, 0.5, 0.5), set up in the emit, search for p->scale.

Also played with buoyancy by impulsing the bubble particles an arbitrary upward force, but remember, z points upward instead of y. Comment it in SPH_ComputeForceGridNC, search for force.z += to avoid it;

MRI update

Implemented all of the variables in global_init in solver.h/cpp

however, the variable po_2 might be modified in the file params.txt, which I don't know what exactly it means.

Also got one parameter in v_init, which is refImage = 10

Version Control Using SVN

We can use SVN, which is very widely applied as a version control cooperation software develop platform in industry, to control version.
Several platforms that support SVN:
unfuddle
googlecode

When share with others, sub users may have such problems that “Can’t create directory” . One way to solve it is to change the permissions of the owner.
The owner can change permissions using linux command 770(first seven for owner, 4-read-2-write-1-execute, second seven for other users, the same; zero for outers, non permissions


Before doing modifications, use SVN update
After doing modifications, use commit SVN

PartTime Job--MRI Ventilation Tips

main_single:

set_path : find the folder's path which contains the fdf files and the "params.txt"

load_params: get params values from "params.txt"

global_init: get initialized parameters

load_data:

v_init: not very useful, get the reference image as the tenth one

grid data: compute bin,

alpha_0 = 4 without alpha mode as initial setups

vent_abs2: fitting started

plot_results:results plotted

save_results:results saved

Read data to RAM in the function: image_ buffer::map_signal(const int & FrameNum);
Added the parameter of SignalStrength to division class to store signal sum in grids
Added "division * frames[FrameMax]" to image_buffer to store division data for 15 frames