Grasshopper

algorithmic modeling for Rhino

i work for the database plugin again. and i need to say, as far as i am it looks pretty cool. but i still have on problem i can't solve myself.

i did some network extension, so multiuser can access a database hosted on a server.

till now i did extensive testing and i found this:

there are some objects i can save like :vectors, points, strings,
float and integer and there are lots i can't like: planes, breps
(surfaces), lines, circles, ... the items i save can be accessed by many
users and are persistent. but the ones i cannot save correctly, i
can just use in the single instance of the program with my .dll i created
them and stored them in the database - as long as i don't close the program.
it's like there is some sort of connected to something going on in the
memory. some of the unsaveable items create an error message when i
try to access them from a second account like : nullplane, line (0.00mm)
or invalid circle, while others just crash rhino (some sort of
display error).

i know grasshopper has classes for every geometry (like point, plane, line, vector and so on), but for simplification i saved e.g. a List as a List, when using "inmemory mode" this works fine. i thought this would be my mistake now, but in an other test i remove all converting steps (i set all types to GHBrep and tried to save a GHBrep) without success again. maybe on of you has a clue why points and vectors work while breps dont?

thanks,
matthias

Views: 773

Replies to This Discussion

Hi Matthias,

for this to work there would have to be proper (de)serialization in place. Points may be smart enough to deserialize themselves from "0.5, 4.5, -9", but a Brep cannot deserialize itself from "Closed Brep".

I don't know how data is written to the database. Is it anything more advanced than calling ToString() on the object?

At any rate, Grasshopper cannot serialize Curves, Surfaces, Meshes and Breps either. For this you'll need to use some sort of OpenNurbs functions to convert these types into byte-arrays which can then be stored on your database.

I'll need to pass you on to Steve Baer for this, he knows more about the deserialization stuff than me.

--
David Rutten
david@mcneel.com
Seattle, WA
thanks david, now i know what i'm looking for.

btw the database stores objects without splitting into tables, e.g:

// Create the object we would like to work with.
Cinema cinema = new Cinema() {
Location = "Sydney",
OpenDates = new DateTime[] { new DateTime(2003, 12, 10), new DateTime(2003, 10, 3) }
};

// And here is where the magic begins...
// Store the object - no conversion required.

db.Store(cinema);

(Eloquera Help)

this simplicity and the fact that eloquera is one of the fastest solutions where reasons i chose this database.
Steve and me have been looking at the Eloquera docs for a bit. We're pretty certain it's working on Points and Vectors because we decorated those types with the [Serializable()] attribute.

We should do the same for Brep, Curve etc. but that will take quite a bit of work. It's also not near the top of the list of things that need to happen before we ship V5.

The most important question in the meantime is what sort of control you have over how and when Eloquera serializes and deserializes its data.

--
David Rutten
david@mcneel.com
Seattle, WA
hi david!

i discussed the topic with some eloquera developers, and i need to say that slowly i'm reaching the limit of my coding abilities. here my last info:
The Eloquera DB does not need the class to be marked as [Serializable] in order to be persist its instances. And there is a possibility that one of the base classes uses [NotSerialized] for some of its fields. Then, the database will respect the attribute, and will not persist such fields. Another possibility is that some of the fields are marked as readonly (a C# keyword), and they cannot be updated outside of the class' constructor. There is a way to overcome this, but it is not yet available through public methods as modification of readonly fields can have some nasty side effects in the applications.

i think you know the definitions better than anybody else, do some classes use [NotSerialized] for some of it's fields or are some marked as 'readonly'? i would forward this information to the eloquera team, they seem positive to find a solution.

thanks,
matthias
Hi Matthias,
I'm pretty sure that these classes need to be made serializable for this to work. Many of the geometry classes in RhinoCommon are layered on top of unmanaged C++ classes which means that Eloquera has no way of figuring out all of the internal pieces of the RhinoCommon geometry class is unless explicitly provide a way for the classes to be serialized.
Thanks,
-Steve
hi steve,

i'm afraid you're right. but the one thing i can't understand is why e.g. circles, lines, etc won't work either. i looked into the definition, and the only difference i found out is the additional DebuggerDisplay("({m_x}, {m_y}, {m_z})"). would you please explain this a little further for me. i really try to understand this.
many thanks so far,
cheers
matthias
The DebuggerDisplay attribute allow you to look at an instance of the type in a debugger window and see what value it has. If we didn't add DebuggerDisplay then all you'd see is the type name and not it's value. It does nothing to help (de)serialization.

--
David Rutten
david@mcneel.com
Seattle, WA
thanks for your answers david and steve, you helped me a lot in understanding this matter.

cheers,
matthias
theoretically it would be possible to cast data from an original "GH_Brep" (which is {get;] only) into a new class "My_Brep" (which would be {get;set;} and write this back into a new "GH_Brep" per using System.Reflection. like in this simple example:

using System;
using System.Collections.Generic;
using System.Text;
using System.Collections;
using Eloquera.Client;
using System.Windows.Forms;
using System.Reflection;

namespace RemoteExample
{
public class my_EDB
{
[Index]
public string Group { get; set; }
[Index]
public string Type { get; set; }
[Index]
public string OriginID { get; set; }
[Index]
public string Data { get; set; }
}
public class EDB
{
private string mGroup = "testgroup";
private string mType = "testtype";
private string mOriginID = "testoriginid";
private string mData = "testdata";
[Index]
public string Group { get{return mGroup;}}
[Index]
public string Type { get { return mType; } }
[Index]
public string OriginID { get { return mOriginID; } }
[Index]
public string Data { get { return mData; } }
}


public class example
{


public static void Main(string[] args)
{
my_EDB test3 = new my_EDB()
{
Group = "MYGROUPNAME",
Type = "test1",
OriginID = "ecfd2a5c-2585-4b7d-bc4f-8a33ce0a84f6",
Data = "xxxxxxxx"
};

EDB test2 = new EDB();
EDB test4= new EDB();

Console.WriteLine("test:");
Console.WriteLine(test3.Group);
Console.WriteLine(test3.Type);
Console.WriteLine(test3.OriginID);
Console.WriteLine(test3.Data);
Console.WriteLine("-----------------------");
Console.WriteLine("test2:");
Console.WriteLine(test2.Group);
Console.WriteLine(test2.Type);
Console.WriteLine(test2.OriginID);
Console.WriteLine(test2.Data);

FieldInfo field = typeof(EDB).GetField("mGroup",
System.Reflection.BindingFlags.Instance |
System.Reflection.BindingFlags.NonPublic);
field.SetValue(test2, test3.Group);


Console.WriteLine("-----------------------");
Console.WriteLine("test2 NEU:");
Console.WriteLine(test2.Group);
Console.WriteLine(test2.Type);
Console.WriteLine(test2.OriginID);
Console.WriteLine(test2.Data);
Console.WriteLine("-----------------------");
Console.WriteLine("test3:");
Console.WriteLine(test4.Group);
Console.WriteLine(test4.Type);
Console.WriteLine(test4.OriginID);
Console.WriteLine(test4.Data);

MessageBox.Show("closewindow");
}
}
}


for sure this would be pretty sloppy, but i think it could do it's job as a workaround, until the other grasshopper types got an added "set{}" to the properties and become writeable too. of course i don't know how complicated this will be, but maybe i give it a shot. first of all i'm afraid i have to do other stuff again.
Hi. eloquera dont work on my gh 0.80xxx
is it because of gh version?
i tested i in 8.0001 and 8.0003 so far, and it worked. do you get any kind of error message? and which os are you working on? a possible cause is also your firewall is blocking the communication to the included server file. (i'm afraid my testing with the first alpha i posted here wasn't this extensive, so maybe i overlooked something.)
win 7_64

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service