Rob
I sent you a zip demo cutdown deploy off list that just loads the test
dice, I figured since you know me from Lfpug you would not be worried
to open, it has some controls and init in xml but sliders negative
control was not working so need to fix pyro for better demo rig.. left
it with just positive control, but since there are awaystats as well
you should have plenty of info. The difference is that in previous
versions z-order worked when camera z=0 ( irrespective of other
coordinates changed ) but now doesn't, if you need a compile with old
away let me know, maybe us setting camera z>0 is wrong, I think it was
just some default values so did not notice till the engine change -
but was assuming it would be a swap out engine - probably my mistake.
;j
On 15 Sep 2010, at 22:12, Rob Bateman wrote:
Hey Jim
for the die example - can you let me know what camera settings you
are using? it looks quite isometric - there have been changes to the
sorting methods and while they are an overall improvement on speed,
there could be some teething troubles ot iron out with uncommen
camera configurations. let us know
cheers
Rob
On Wed, Sep 15, 2010 at 8:21 PM, [email protected] <[email protected]
> wrote:
Ok I have commented out a some functionality on my GhostMaterial and
it was actually not hard to get working for what we need, so my
panic over... that part is working.
But we are noticing that for a low poly dae the z-sorting is not as
good? We tried it in the mario example and it seemed to render
fine, but within our systems setting the die looks decidedly
unstable flickering z-layers see screenshot. On some other tests we
are getting faces disappearing. Need to look into it further but is
this to be expected?
<screenshot_01.png>
Cheers ;j
On 15 Sep 2010, at 18:44, [email protected] wrote:
Rob
Slightly shocked to see how much materials have changed, trying to
work out if my GhostMaterial will still work once I try to update
the render* methods, or if I have to revert to previous version of
Away3d.
Basically GhostMaterial can be used as null material or proxy
events to a real material, I am mostly using it to make for more
flexible control over BSPTree face material ( animate ) and also to
allow very simple AWD file to be collision BSP for a more complex
model by effectively providing empty render methods so that it does
not show but is used for collision.
Anyway as I don't really follow the changes or their reason can you
comment a bit about why and on if it will still be feasible for me
to update GhostMaterial, or will the changes likely to make render
proxying impossible or are there some side effects I need to be
aware of? I guess I could just try, but does seem a lot more
complex :(
GhostMaterial below.
Many thanks
Justin
package away3dextensions.materials
{
import away3d.arcane;
import away3d.containers.*;
import away3d.core.base.*;
import away3d.core.draw.*;
import away3d.events.*;
import away3d.materials.Material;
import away3d.materials.WireframeMaterial;
import flash.events.*;
use namespace arcane;
/**
* GhostMaterial class
* @author JLM at justinfront dot net
*
*/
public class GhostMaterial extends WireframeMaterial
{
private var _soul: Material = null;
private var _bodies: Object = {};
private var _segs: Object = {};
private var _tris: Object = {};
private var _sprites: Object = {};
private var _ghost: Boolean = true;
private var _view: View3D;
private var _faces: Vector.<Face>;
private var _updateAll: Boolean = false;
/** @private */
arcane override function updateMaterial(source:Object3D,
view:View3D):void
{
_view = view;
if( !_ghost )
{
_soul.updateMaterial( source, view );
if( _soul[('autoUpdate')] == true )
{
notifyMaterialUpdate();
}
}
else
{
_bodies[ source ] = source;
}
}
/** @private */
arcane override function renderSegment(seg:DrawSegment):void
{
if( !_ghost )
{
_soul.renderSegment( seg );
}
else
{
_segs[ seg ] = seg;
}
}
/** @private */
arcane override function
renderTriangle(tri:DrawTriangle):void
{
if( !_ghost )
{
_soul.renderTriangle( tri );
}
else
{
_tris[ tri ] = tri;
}
}
/** @private */
arcane override function renderSprite(sprite:DrawSprite):void
{
if( !_ghost )
{
_soul.renderSprite( sprite );
}
else
{
_sprites[ sprite ] = sprite;
}
}
/**
* Duplicates the material properties to another material
object. Usage: existingMaterial =
materialToClone.clone( existingMaterial ) as GhostMaterial;
*
* @param object [optional] The new material
instance into which all properties are copied. The default is
<code>GhostMaterial</code>.
* @return The new material instance
with duplicated properties applied.
*/
public override function clone(material:Material =
null):Material
{
var mat:GhostMaterial = (material as GhostMaterial) ||
new GhostMaterial( _soul );
return mat;
}
/**
* If you need to not render a material then you can pass
it to a ghost and save the materials Soul till you need it again
*
* @use
* model.material = new GhostMaterial( model.material );
*/
public function GhostMaterial( mat_: Material = null )
{
_soul = mat_;
}
// allow change of soul
public function set soul( soul_: Material )
{
_soul = soul_;
}
public function get soul():Material
{
return _soul;
}
//Not used often.
public function resurrect()
{
for( var all: String in _bodies )
{
( _bodies[all] as Mesh ).material = _soul;
}
var loop:int = _faces.length;
var face: Face;
for( var i:int = 0;i<loop;++i)
{
face = _faces[i];
face.material = _soul;
}
//somehow need to delete itself???
}
public function ghostfaces( faces_: Vector.<Face> )
{
_faces = faces_;
var loop:int = faces_.length;
var face: Face;
for( var i:int = 0;i<loop;++i)
{
face = faces_[i];
face.material = this;
}
}
// always update all on ghost change
public function set alwaysUpdateAll( updateAll_: Boolean )
{
_updateAll = updateAll_;
}
public function get alwaysUpdateAll():Boolean
{
return _updateAll;
}
private function updatefaces()
{
var loop:int = _faces.length;
var face: Face;
for( var i:int = 0;i<loop;++i)
{
face = _faces[i];
face.notifyMappingChange();
}
}
public function set ghost( ghost_: Boolean )
{
if( _ghost == ghost_ )
return;
_ghost = ghost_;
updatefaces();
// only update everything if really needed ( not needed
if BSPTree )
if( _updateAll )
{
updateAll();
}
}
public function get ghost()
{
return _ghost;
}
private function updateAll()
{
var all: String;
for( all in _bodies )
{
( _bodies[ all ] as Mesh ).notifyDimensionsChange();
}
for( all in _segs )
{
( _segs[ all ] as DrawSegment ).render();
}
for( all in _tris )
{
( _tris[ all ] as DrawTriangle ).render();
}
for( all in _sprites )
{
( _sprites[ all ] as DrawSprite ).render();
}
_view.render();
}
}
}
On 14 Sep 2010, at 14:47, Rob Bateman wrote:
Hey guys
today an update has been made to the main fp10 trunk that
incorporates a few major refactors. The impact of these on code
compatibility should be minimal, but there are a few necessary
changes that have had to be made as we move forward.
First of all, we have (finally) replaced all MatrixAway3D
references with fp10's native Matrix3D class. This has allowed us
to switch to faster projection techniques for vertices, which
should for the majority of Away3D apps be seen as a slight speed
increase. There have also been some other optimising measures
brought in from Lite, such as radix sorting of faces, etc
In the interest of improved memory handling, there have also been
a huge amount of updates carried out to improve memory
consumption, and provide a more stable memory base. This is not
yet perfected, but the majority of applications should see
improvements here as well
Following on from memory optimisations, both screenvertex and
number3d now inherit from vector3d. These changes mean a slight
alteration will be required for any apps that use these classes.
Primarily, the differences lie in the way these objects are added,
subtracted etc. Where previously you would add two number3d
objects by doing:
new number3DResult:Number3D - new Number3D();
number3DResult.add(number3D1, number3D2);
you will now need to do:
new number3DResult:Number3D = number3D1.add(number3D2);
The old player 9 memory problems of generating extra number3d
instances are no longer an issue in 10.1, and the above way of
working is generally considered a standard when dealing with 3D
vectors, hence the change. The same thing follows for the native
Matrix3D class - where before you would transform a number3d with
the following:
new number3DResult:Number3D - new Number3D();
number3DResult.transform(oldNumber3D, transformMatrix);
you can now do the same using native objects:
new vector3DResult:Vector3D =
transformMatrix.transformVector(oldVector3D);
aside from these slight syntactic changes, the engine should
operate as normal. If anyone experiences any bugs, please report
them in this thread!
Enjoy the new release!
Rob
--
Rob Bateman
Flash Development & Consultancy
[email protected]
www.infiniteturtles.co.uk
www.away3d.com
--
Rob Bateman
Flash Development & Consultancy
[email protected]
www.infiniteturtles.co.uk
www.away3d.com
