[x3d-public] X3D Java SAI. Declarative style
Joe D Williams
joedwil at earthlink.net
Thu Jan 19 09:29:25 PST 2017
----- Original Message -----
From: "John Carlson" <yottzumm at gmail.com>
To: "Don Brutzman" <brutzman at nps.edu>
Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>
Sent: Thursday, January 19, 2017 8:32 AM
Subject: Re: [x3d-public] X3D Java SAI. Declarative style
> While I appreciate the style, I think it's harder to debug and edit
> from a
> human point of view. I am not compromising to make it easier for
> the java
> compiler.
So that it is the current data structures being advanced move toward
data storage in forms convient for the back end rather than human
readability or functional groupings ... more toward machine
convenience, to me, kind of like the direction of vulcan and xflow
definitions. This gives certain advantages of reusability, perhaps,
but usually means that a basic human-readable form is unlikely or
needs a highly level editing tool.
> I like to make it easier for humans. What this style lacks is
> tag names, which are vital for debugging. That is, what type do I
> need to
> add this method to if the compiler fails. Since the SAI can support
> both
> styles, I suggest we keep yours as an optimization in some
> serializer
> somewhere. Let's discuss. In otherwords, having distinct
> variable names
> gives you a handle to work with debugging. If the was a
> programming
> language which supported both styles, it would be ideal.
Hi Don,
In reading that example, it seems more like a language of an
implementation, rather than documentation of x3d utf-8 user code. Why
not use the SAI for this?
>> Pretty darn cool.
I agree, Do we have a java player that does skin?
Thanks and Best,
Joe
>
> On Jan 19, 2017 9:19 AM, "Don Brutzman" <brutzman at nps.edu> wrote:
>
>> I read a very interesting book on the flight to Korea. This
>> cleared up
>> several mysteries for me... highly recommended.
>>
>> *Functional Programming in Java: Harnessing the Power of Java 8
>> Lambda
>> Expressions, Venkat Subramaniam, Pragmatic Bookshelf, Dallas Texas,
>> 2014.
>> https://pragprog.com/book/vsjava8/functional-programming-in-java
>>
>> John, here is a new style of coding that mostly eliminates the need
>> for
>> declaring each and every object.
>>
>> Benefits include more concise, no side effects, no need to keep
>> track of
>> names for object instances, automatically parallelizable by
>> compiler.
>> Syntax looks a lot like node.js style.
>>
>> I picked a scene that shows ProtoDeclare, Script, fields,
>> IS/connect and
>> CDATA source code to get a good workout. The only object member is
>> "scene", everything else is local.
>>
>> New code block in HelloWorldProgram.java:
>> =============================================
>>
>> /** Test declarative style, prototype fields and scripting
>> */
>> private void addMaterialModulatorModulator ()
>> {
>> ProtoDeclareObject materialModulatorPrototype = new
>> ProtoDeclareObject ("MaterialModulator");
>> materialModulatorPrototype
>> .setAppinfo("mimic a Material node and
>> modulate
>> fields as an animation effect")
>> .setDocumentation("http://x3dg
>> raphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes/M
>> aterialModulatorIndex.html")
>> .setProtoInterface(
>> new ProtoInterfaceObject()
>> .addField(new fieldObject
>> ()
>> .setName("enabled")
>>
>> .setType(fieldObject.TYPE_SFBOOL)
>> .setAccessType(
>> fieldObject.ACCESSTYPE_INPUTOUTPUT)
>>
>> .setValue(SFBoolObject.TRUE))
>> .addField(new fieldObject (
>> "diffuseColor",
>> fieldObject.TYPE_SFCOLOR,fieldObject.ACCESSTYPE_INPUTOUTPUT,
>>
>> (SFColorObject.toString(SFColorObject.DEFAULT_VALUE))))
>> .addField(new fieldObject (
>>
>> "emissiveColor",fieldObject.TYPE_SFCOLOR,fieldObject.ACCESST
>> YPE_INPUTOUTPUT,
>>
>> Integer.toString(0x000080)))
>> //
>> SFColorObject.toString(0x000080))) // TODO fix
>> // TODO
>> major side
>> effect follows that affects all MaterialObject specularColor
>> values, why?
>> // design
>> change
>> needed to make things work? how to prevent user from provoking it?
>> // (new
>> SFColorObject(0.05f, 0.05f, 0.85f)).toString()))
>> .addField(new fieldObject (
>>
>> "specularColor",fieldObject.TYPE_SFCOLOR,fieldObject.ACCESST
>> YPE_INPUTOUTPUT,
>>
>> (SFColorObject.toString(SFColorObject.BLACK))))
>> .addField(new fieldObject (
>> "transparency",
>> fieldObject.TYPE_SFFLOAT,fieldObject.ACCESSTYPE_INPUTOUTPUT,
>> "0.0"))
>> .addField(new fieldObject (
>> "shininess",
>> fieldObject.TYPE_SFFLOAT,fieldObject.ACCESSTYPE_INPUTOUTPUT,
>>
>> Float.toString(0.0f)))
>> .addField(new fieldObject (
>>
>> "ambientIntensity",fieldObject.TYPE_SFFLOAT,fieldObject.
>> ACCESSTYPE_INPUTOUTPUT,
>>
>> SFFloatObject.toString(0.0f)))
>> //
>> .setChildren((MaterialObject newMaterial = new MaterialObject
>> ("MaterialNode"))))
>> // TODO fix syntax
>> or add
>> utility methods
>> );
>> ProtoBodyObject materialModulatorProtoBody = new
>> ProtoBodyObject();
>> materialModulatorPrototype.set
>> ProtoBody(materialModulatorProtoBody);
>> materialModulatorProtoBody.addChildren(
>> new MaterialObject("MaterialNode")
>> .setIS(new ISObject()
>> .addConnect(new
>> connectObject().setNodeField("diffuseColor"
>> ).setProtoField("diffuseColor"))
>> .addConnect(new
>> connectObject().setNodeField("emissiveColor"
>> ).setProtoField("emissiveColor"))
>> .addConnect(new
>> connectObject().setNodeField("specularColor"
>> ).setProtoField("specularColor"))
>> .addConnect(new
>> connectObject().setNodeField("transparency"
>> ).setProtoField("transparency"))
>> .addConnect(new
>> connectObject().setNodeField("shininess"
>> ).setProtoField("shininess"))
>> .addConnect(new
>> connectObject().setNodeField("ambientIntensity").setProtoFie
>> ld("ambientIntensity"))
>> ));
>> materialModulatorProtoBody.addChildren(
>> new CommentsBlock ("Only first node (the
>> node
>> type) is renderable, others are along for the ride"));
>> materialModulatorProtoBody.addChildren(
>> new ScriptObject
>> ("MaterialModulatorScript")
>> .addField(new
>> fieldObject().setName("enabled").setType(fieldObject.TYPE_SFBOOL)
>>
>> .setAccessType(fieldObject.ACC
>> ESSTYPE_INPUTOUTPUT))
>> .addField(new
>> fieldObject().setName("diffuseColor").setType(fieldObject.TYPE_SFCOLOR)
>>
>> .setAccessType(fieldObject.ACC
>> ESSTYPE_INPUTOUTPUT))
>> .addField(new
>> fieldObject().setName("newColor").setType(fieldObject.TYPE_SFCOLOR)
>>
>> .setAccessType(fieldObject.ACC
>> ESSTYPE_OUTPUTONLY))
>> .addField(new
>> fieldObject().setName("clockTrigger").setType(fieldObject.TYPE_SFTIME)
>>
>> .setAccessType(fieldObject.ACC
>> ESSTYPE_INPUTONLY))
>> .setIS(new ISObject()
>> .addConnect(new
>>
>> ectObject().setNodeField("enabled" ).setProtoField("enabled"))
>> .addConnect(new
>> connectObject().setNodeField("diffuseColor").setProtoField("
>> diffuseColor")))
>> .setSourceCode(new
>> String("ecmascript:\n" +
>> "function initialize ()\n" +
>> "{\n" +
>> " newColor = diffuseColor; // start with correct color\n" +
>> "}\n" +
>> "function set_enabled (newValue)\n" +
>> "{\n" +
>> " enabled = newValue;\n" +
>> "}\n" +
>> "function clockTrigger (timeValue)\n" +
>> "{\n" +
>> " if (!enabled) return;\n" +
>> " red = newColor.r;\n" +
>> " green = newColor.g;\n" +
>> " blue = newColor.b;\n" +
>> " \n" +
>> " // note different modulation rates for each color component, %
>> is
>> modulus operator\n" +
>> " newColor = new SFColor ((red + 0.02) % 1, (green + 0.03) % 1,
>> (blue +
>> 0.04) % 1);\n" +
>> " if (enabled)\n" +
>> " {\n" +
>> " Browser.print ('diffuseColor=(' + red +',' + green
>> + ',' +
>> blue + ') newColor=' + newColor.toString() + '\\n');\n" +
>> " }\n" +
>> "}")));
>> scene.addChildren(materialModulatorPrototype);
>> }
>>
>> =============================================
>>
>> Pretty darn cool. Some more work to follow on my part to tighten
>> up need
>> to repeat addChildren calls for every individual child and source
>> text, but
>> this is a big step.
>>
>> When ready I recommend you shift to declarative style to avoid need
>> to
>> generate individual objects with unique suffixes.
>>
>> all the best, Don
>> --
>> Don Brutzman Naval Postgraduate School, Code USW/Br
>> brutzman at nps.edu
>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>> +1.831.656.2149
>> X3D graphics, virtual worlds, navy robotics
>> http://faculty.nps.edu/brutzma
>> n
>>
>
--------------------------------------------------------------------------------
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
More information about the x3d-public
mailing list