Skip to content

kjb14001/2015SweetHome3D

master
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Code
This branch is 4 commits ahead of ofk13001:master.

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
 
 
 
 
 
 
This is the project of Group 29 in CSE2102 in Spring 2016.

We're all learning git! Yay!

Test - By Keelin
Test - By Jon

Notes from Feb. 20th:

We found HomeController3D.java, which has private (!)
class CameraControllerState, and in particular a
subclass of that called ObserverCameraState

Also, it has
      elevateCamera(float delta)
      moveCamera(float delta)

model/ObserverCamera.java
      Has setX and setY, which are used for movement.
      Has intersectsRectangle()

Home.getObserverCamera

Notes from March 25th:

Stright wall collisions have already been implemented. Now for arched walls.

In model.Wall.java:
      getUnjoinedShapePoints() has code to get values describing the arc and its circle.
      computeRoundWallShapePoint() has code to get points on arc of circle

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Oliver's notes from April 16th:

These notes concern what I've done in my refactor-collision
branch as well as what I know we should do to wrap up this
project.

I've added what I think is the beginning of
a decent infrastructure for collision (with walls,
furniture, and anything else we decide to add, because
making new things Collideable should be straightforward).

(I've ignored everything to do with the z-axis, like
the height of walls, for now. However, you could build certain
n-dimensional barriers / shapes out of the classes I have made.)

Collideable interface:
One function, which returns a MovementValidator.

(BEGIN details of collideable subclasses. This is half of the work
that remains, and you can pursue either half without knowing
what the other half is, I think.)

MovementValidator interface:
Once method, which can say whether a movement from point A
to point B is possible or not (with respect to a particular
wall or other Collideable thing.)

HitBox abstract class implements MovementValidator:
A hitbox is an area you can't walk into.
If you find yourself in the HitBox by accident,
e.g. because of changing levels, you can walk
out, but you can't walk in again.
This will be handy for furniture.

Barrier abstract class implements MovementValidator:
A barrier is a curve that you cannot cross.

LinearBarrier class extends Barrier:
Can do collision for anything shaped like a straight wall.

(END details of Collideable)

We need to:

1. Finish making Wall.java implement collideable

2. Figure out where to keep a list of all Collideable items
   that will stay up to date. (We can also make it a list of
   EventValidators)

3. Add EventListeners to update the collideable list appropriately
   when the following events happen:
	Selected level changes (see HomeController3D)
	Camera state changes (see HomeController3D)
	Wall is added (see Home.java)
	Wall is removed (..)
	Wall is changed (see Wall.java)
	(Keelin, how did you do distance to a wall?)
	
(RE event listeners, see:
java.beans.PropertyChangeEvent;
java.beans.PropertyChangeListener;
com.eteks.sweethome3d.model.CollectionEvent;
com.eteks.sweethome3d.model.CollectionListener;
com.eteks.sweethome3d.model.SelectionEvent;
com.eteks.sweethome3d.model.SelectionListener;

Look at the documentation as well as how they are used
in classes like HomeController3D, Home, Wall, etc.)

Unless somebody figures out something more elegant,
here will be the process of making collision with
SomeClass work:

1. make SomeClass implement Collideable
   (This may involve writing or extending
   a new MovementValidator)

2. Add EventListeners to detect when the collision-relevant
   properties of each instance of SomeClass. The listeners'
   propertyChange(..) methods should update the Collideable list.

   (In cases, it may be necessary to add infrastructure,
   i.e. events to listen to.
   This will involve modifying Propery enums (I think)
   and making various methods call
   this.propertyChangeSupport.firePropertyChange(... args)
   See Wall.java, line 160.)

3. I think that's all.

Releases

No releases published

Languages

  • Java 50.0%
  • HTML 49.8%
  • Other 0.2%