I managed to compile a viewer.
It was crashing a lot.
I have many, many fixes which I could commit if anybody is intereseted.
It seems that with the prototypes support the toolkit has been taken in a somewhat
wrong direction:
First, It crashes when a feature is unsupported.
Second, the proto handling is implemented in the xerces loader, which I believe is wrong.
It seems that the Proto related nodes should be handled as regular nodes,
and processed later just as the Inline nodes are. THis would also allow
handling of external prototypes.
I will probably end up using a proto-stripped version of the toolkit for now.
The library is big and I cannot keep fixing things without fully understending them.
Regards,
Nikolay Mladenov
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've got X3DTK working (as far as I can tell). I'm VERY leery of letting anyone besides the 3 of us who work on it commit code. I would be happy to look over your code and then commit it myself. If we do this a few times, I would trust you and then give you the keys to code. :)
Prototypes:
I very well might have screwed this up. I had to do a lot of work from scratch while trying to figure out exactly what the heck Le Gok was thinking.
a) Crashing with an unimplemented feature is clearly bad. This is my fault. I work on this project when my boss tells me to... so its got time deadline pressure and all the quality code that this entails. If you email me a file that crashes it, I'll try to get it fixed.
b) I don't fully understand this statement. I'll dig back into the code and look at how I implemented the Protos. Proto's can be quite an odd bird, I'm not 100% certain I understand everything that CAN be done with them. I'd be happy to work with you if you can point out how the library is deficient.
Do you use an instant messenger and where are you? Kristian, being in Germany, has to schedule a time when we can talk since I am in the USA.
Larry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
4. Changed the BBoxUpdaterStateVariables class to use map instead of list for
its bounding box cache. This resulted in HUGE speed up ( O(N2) vs. O(NlogN) ) .
(I could not wait for one of my models to load before that)
the change affects 2 files
5. added X3DTK_STATIC definition check to support static lib build on windows.
6. I made changes to the xerces loader and improved the situation a bit but I
stil have problem models and I do not like the way the code develops.
Regards,
Nikolay
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To be honest I haven't gone over the code with a fine tooth comb. I'll add you to my messanger services and we can get to work on this some weekend or something.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I managed to compile a viewer.
It was crashing a lot.
I have many, many fixes which I could commit if anybody is intereseted.
It seems that with the prototypes support the toolkit has been taken in a somewhat
wrong direction:
First, It crashes when a feature is unsupported.
Second, the proto handling is implemented in the xerces loader, which I believe is wrong.
It seems that the Proto related nodes should be handled as regular nodes,
and processed later just as the Inline nodes are. THis would also allow
handling of external prototypes.
I will probably end up using a proto-stripped version of the toolkit for now.
The library is big and I cannot keep fixing things without fully understending them.
Regards,
Nikolay Mladenov
Nikolay,
I've got X3DTK working (as far as I can tell). I'm VERY leery of letting anyone besides the 3 of us who work on it commit code. I would be happy to look over your code and then commit it myself. If we do this a few times, I would trust you and then give you the keys to code. :)
Prototypes:
I very well might have screwed this up. I had to do a lot of work from scratch while trying to figure out exactly what the heck Le Gok was thinking.
a) Crashing with an unimplemented feature is clearly bad. This is my fault. I work on this project when my boss tells me to... so its got time deadline pressure and all the quality code that this entails. If you email me a file that crashes it, I'll try to get it fixed.
b) I don't fully understand this statement. I'll dig back into the code and look at how I implemented the Protos. Proto's can be quite an odd bird, I'm not 100% certain I understand everything that CAN be done with them. I'd be happy to work with you if you can point out how the library is deficient.
Do you use an instant messenger and where are you? Kristian, being in Germany, has to schedule a time when we can talk since I am in the USA.
Larry
I am in Canada.
Instant messaging - yes:
icq : 17507415
yahoo : nikiml
msn : nikiml@hotmail.com
I can send you a diff file for the changes I have. Let me know the diff options you prefer.
The summaray of the errors that I fixed is:
1. changed multiple occurences of ( and variations of)
vector<..>::iterator it = ...;
if( *it == ... || it == vec.end() )...
to
if( it == vec.end() || *it == ... )...
those are single line changes not involving anything but swapping the two tokens
2. changed code like that
iterator i = vec1.begin();
if(i == vec2.end()) ....
comparing iterators of two different containers is undefined
those changes are a bit bigger, but they also led to some speed up.
3. changed defineTypeName function to a template function in order to
get the cloning to work:
- defineTypeName("Scene", "Core"); //became
+ defineTypeName(this, "Scene", "Core");
those are single line changes on many files
4. Changed the BBoxUpdaterStateVariables class to use map instead of list for
its bounding box cache. This resulted in HUGE speed up ( O(N2) vs. O(NlogN) ) .
(I could not wait for one of my models to load before that)
the change affects 2 files
5. added X3DTK_STATIC definition check to support static lib build on windows.
6. I made changes to the xerces loader and improved the situation a bit but I
stil have problem models and I do not like the way the code develops.
Regards,
Nikolay
Ahhh...
That all looks like REALLY good additions.
To be honest I haven't gone over the code with a fine tooth comb. I'll add you to my messanger services and we can get to work on this some weekend or something.
I could send you a diff?
Sure.