Sunday, 18 December 2011
What's about Microsoft initiative named: Going Native? This is Microsoft's attempt to promote C++ 11 standard and future Visual Studio version that will improve the broken C++/.Net bridges.
Which are the reasons? Basically: using VNext (the "codename" for the next version), you will have outline of your code like you were able to do for some time in Eclipse CDT plugin.
The problem is in my understanding not the marketing part, which is cool (as is presented in the first part), like you can get the ultimate performance as you can get the ultimate control, you can map in shared memory, so another process can reuse your data and other "cool stuff like that". In fact I've got it, you can get huge performance using those constructs, yet the problem is after how many years, after how much testing. The reason that I was sold out for .Net languages is the service part: language have rich support for type information (named reflection or RTTI), which makes that the compiler to rarely fail on code completion, have saner defaults for memory management and decent performance. Where in NaroCAD performance was the issue, was because of the wrong algorithms, or not profiling the code.
The last days I was working with wrappers for OpenCascade 6.5.x. I was fairly surprised of how fast the compilation of C++ code works (as machines are much powerful as they were some years ago) and even I did not finish to port them, I've noticed some parts that were overall slow: disk access, the number of frameworks that NaroCAD use (by default NaroCAD uses WPF which is DirectX wrapped by a framework CodeCLR, .Net, OpenGL and OpenCascade, GDI+ (to host OpenGL/Occ window)). If it would be no framework, or Windows would have a way that frameworks will be always up-and-running, I think that NaroCAD would start (close-to) instantly.
So at the end I felt that this is why people do not tend to go native: is all about how many things you get for granted with high level languages/platforms: tools to make fast an UI, a great debugger, no chance (excluding a VM bug) to get "Invalid address" errors or like. And at the end a person that would want to extend NaroCAD, would not care at the ultimate performance you may get using a compiler as GCC that would inline differently some parts of the code based on your constants flow, but it would want to have a way to inspect the API, a way to script it (maybe using Boo), a way to import Step files and to export them back.
If and when NaroCAD will be performance bound, I do think that the way to improve it is: be multi-threaded (to be able to use the AMD's 8 cores, by using parallel extensions), be multi-process and distribute over the network (as WCF permit that much easily than any C++ framework I know it would be able to).
At the end the trend of using native is true for phones, and I agree that there are "native" ways to improve your performance for limited hardware, but NaroCAD as it stands, I don't see it that to happen any time soon. And if (ever) NaroCAD would work on an Android or IPad class hardware, it would take at least 1-2 years to complete it, so maybe it would address the hardware that would exist at that time, and it would be likely at least an ARM dual core (as is iPad 2) or ARM quad core (as is NVidia Tegra 3), where the stated arguments (multi-core and maybe multi-process) remain the way to improve. And the framework to use? Maybe Mono Touch and Mono for Android.
Wednesday, 14 December 2011
Among the features we planned are:
- Enhance the solver: make it faster and more reliable,
- Update to OpenCascade 6.5.X and enhance wrappers,
- Fix the 2D tools and make a more stable release,
- Improve docs and strengthen the unit tests.
After the Sketching part will be ok we'll start fixing the 3D features.
At the beginning the development progress will be slower, in a month planning to contribute at full speed.
Monday, 19 September 2011
First step would be stabilizing the 2D tools and enhance solver to be faster and restrict it to find solutions that affect only the current shape, not the entire scene.
Wednesday, 29 June 2011
It also catches line mid points and axis origin.
Saturday, 25 June 2011
Will try to isolate bugs in unit tests before fixing them.
Friday, 24 June 2011
Thursday, 23 June 2011
In order to show some progress on the Naro feature side will start bug fixing and enhancing it leaving the 6.5.X porting as a secondary task. The problem doesn't seem to be be on the wrapper side but seems to be caused by different usage on the OpenCascade side. Tried also playing with the OCC environment settings (like changing the memory allocator and multithreading), the problem doesn't seem to be on that side.
Wednesday, 15 June 2011
Friday, 10 June 2011
One big fix was made: the IsSameTransient method was fixed. Now selections work properly on Naro.
Also investigated why Naro's memory increases with usage. With some memory mapper that was tracking allocations and deallocations it seems that all objects are properly deallocated. Added also a CppDisplayLeaks() method that dumps memory leaks in the Output window, nothing dumped as leak.
It seems that at the wrapper level no leaking is made but still the memory increasing while using Naro is suspect, leaking is not completely excluded.
Started researching on crashes when running Naro with OpenCascade 6.5.0, this is the next fix we need to make.
Monday, 6 June 2011
Making the splash screen stay on top on all other application can be very annoying when working with other applications, because it cannot be moved out of the way.
We made this fix after reading the error reports. Thank you for reporting, and don't hesitate to tell us about other problems as well. Other issues might take more time time to fix, but we always keep track of them. You can also discuss on the forum about such problems.
This fix is will be available from the next release and in all nighty builds. Thank you for the cooperation and enjoy NaroCAD.
Saturday, 4 June 2011
The single remaining bug is IsSameTransient equality test and all tooling is ready for OpenCascade 6.5 usage crashes (that will be likely be ported very very soon, before the next release).
Tuesday, 31 May 2011
From user standpoint, will unlikely change it. The wrapper will be a bit smaller, but will make no change in rest.
From developper standpoint, will make possible to build the wrapper and to DEBUG it. The new wrapper also is using open (read: not WOK) build systems, based on XML to declare/expose the APIs, QMake as C++ project generator (even is not a Qt project). The XML parsing to read and expose APIs will make easier to work on long run.
Also, the imported parts are minimal parts we really use in NaroCAD. At the end there are two underlying final migration advantages: we can migrate right now from Visual Studio 2008 to 2010 with a recompilation of NaroCAD (without rebuilding C++ wrappers) and if all work, will be no extra issue. And we can go to 6.5 wrapper stubs in minutes by simply relinking and making easier to debug them, simplifying all runtime based problems we had previously with Visual C++.Net runtime.
Friday, 20 May 2011
How it works: there are three steps build:
- generate a XML API file, this is equivalent of CDL files but is easier to parse and populate. There is a visual tool that will scan from old OCWrappers with reflection and you will pick which methods are used. This API file make distinction between methods and properties.
- from this XML file are generated and updated C# and C++ projects with code. This is the most boring side, but also is where the power stands. The code generator makes patterns of code that are friendlier to debug. Also this part will make sure that the compiled code (mostly C++ side) will not include more than is needed.
- you have to rebuild the updated projects. In a typical workflow you will want to link to the C# project to see if all dependent classes. For now just the string type have to be fixed manually (because strings can be both wide strings and char* strings, two ways or repreenting Unicode and ANSI string encodings). Also, the C++ build is based on QMake (part of Qt SDK) for simplicity.
This design permit to improve all wrapping stack, is also a C# codebase and at the end makes a easier to work with both resulting code and with wrappers in themselves. As when the 6.5 OpenCascade issues will be found, the migration to new wrappers is possible as classes were written in a separate namespace and uses a different naming convention, so from gp_Pnt will get to gpPnt, and functions that return one number, will be likely automatically become properties which make easier for C# used eye.
The C++/C# projects permit to use different compilers (mostly different Visual Studio versions) for C++ side of wrapper/C# side, so makes sense in future to migrate to Visual Studio 2010 (when the C++ wrapper is still using VS 2008) so no binary compatibility issues will be involved.
Tuesday, 17 May 2011
Right now I want to discuss on development on wrappers. In fact, why if things work right, most likely I will try to remove the the original CLI wrappers and to import just the necessary methods/clasess. The design will be a bit different from the actual wrappers and we will try to work using .Net technologies and will extract the information from the existing wrappers.
This approach have many advantages, one of them is the possibility to debug using those wrappers and to make some changes that are at least nice to have for a C#/.Net programmer: automatically using of properties (like gpPnt.X() is better to be used in its property form gpPnt.X and so on), P/Invoke which will make easier to migrate to Visual Studio 2010 (C++ side of wrappers do not need to be recompiled for migrating to VS 2010 for example). This prototype is advanced yet not complete.
This will mean a thing for contributors that were interested in wrappers: is hard for our team to support them and is even harder for every new package to us to investigate why things crash and so on. Also, it make little sense (excluding for making a package) to give wrappers that later will make others' product to crash cause of our fault.
At the end, is just about to separate the codebase and to let as most as possible of C++ behind. If the prototype will not work, we will still use the old wrappers, but if will work (with minimal flaws), we have likely no reason to still use the C++/CLI (aka C++.Net) wrappers. You are still welcome to take Svn snapshot and provide patches and we will include in our Svn tree if you need them and you will want to contribute.
In between I did prepare the code to make previews of constraints persistent (they were shown just in previewing of lines) and if possible to make possible to delete them by selecting and pressing delete. It would be nice if clicking on a constraint to switch automatically to constraint action but this is not also certain.
Wednesday, 11 May 2011
NaroCAD gets new capabilities and big changes happen from inside.
- Constraint automatic detection: so drawing perpendicular, parallel, middle of points will create automatically constraints with the SketchSolve based component. Circle/arc based were also added in default setup (yet are not detected automatically) so you can work with more constraint combinations
- a Fixed-Point constraint was done: this will fix the annoyances that a SketchSolve solution will mess your entire sketch.
- Sketch constraints are previewed (now only with line action) and shows texturing capabilities that will likely permit that more components will use in future this capability
- more sketch related unit tests/Boo scripts will work (fixes are still needed but as they are fixed, easier will be to test crashes and inconsistencies)
-it was investigated and a working OpenCascade 6.5 (ultimate upstream version) wrapper was done. Seems that behavior was changed to work with Opencascade so crashes are not from wrapping side (or should be minimalist) but from usage side. We don't support those wrappers but if someone wants a starting C#/.Net way to work with wrappers you're welcome to use them taking the source or the binaries from SVN repository
Download it from here.
Monday, 9 May 2011
Another development based on work of Sami and bxtrx initially, enhanced, mapped and completed by myself is that points can be constrained. A full action will preview all points initially with blue, and you can constraint them by clicking them and they will transform with red color to know that they are constrained. After that the constraining will not be jumping.
See video here: (made with a virtual machine setup, so sadly it skip frames)
Friday, 6 May 2011
But in a lot of cases this is not needed (to have items sorted by key) and as someone informed me, I will use Dictionary generic class instead in future.
"Retrieving a value by using its key is very fast, close to O(1), because the Dictionary class is implemented as a hash table." Looks like the query time for Dictionary is O(1), but the query time for SortedDictionary is O(logn) -- "The SortedDictionary generic class is a binary search tree with O(log n) retrieval, where n is the number of elements in the dictionary. In this respect, it is similar to the SortedList generic class. The two classes have similar object models, and both have O(log n) retrieval. Where the two classes differ is in memory use and speed of insertion and removal."So, for your better writing code, use Dictioary always.
Fixes are made lately so most of your Boo scripts will work as sketch code is automatically handled, more shapes will also work. Dangling texture rectangles shown in preview of automatic constraints were fixed and are display and will disappear at the end of your design. There is a crash of .Net/C++ memory management that will be fixed before release in this area.
Thursday, 5 May 2011
Implemented a fixed vertical and horizontal point position constraint, made tests with it and it seems to work well. Adding this constraint to Naro will be a must have feature added probably on next week, this will enhance a lot the solver solutions - currently the constrained shapes "jump" on scene because of the solver solutions found.
Friday, 29 April 2011
Unit tests are critical to make a baseline of NaroCAD code to know that errors are in usage of code, and to not propagate all errors to break everything. I will work more to fix them as it appears that where unit-tests are fully broken, most of functionality (at least on Boo scripting level) seem also to be completely broken.
Thursday, 28 April 2011
It seems that on 6.5.0 the installer doesn't set the environment variables anymore. Made a script that launches Naro in Visual Studio previously setting its environment variables.
Some crashes appear when opening and closing local contexts. Possibly something on OpenCascade functionality changed in this area.
Some crashes appear when selecting something. Made a sample movie for this case:
The crashes are not created by adding finalizers at all wrappers, I tested also with wrappers that don't have finalizers and the behaviour is the same. It seems to be generated by some changes on OCC. Investigating this issue will probably take time.
As on next week a Naro release is scheduled will save the wrappers work on this state and change the environment back to 6.3.0 to help at finishing the current release.
Will continue wrapper work after release.
Monday, 25 April 2011
NaroCAD have right now icon previews for applied constraints. And some bug fixes are done to not apply random constraints in tree like: parallel line with itself, or such, making sketch based solver to get crazy in most cases.
Some small issues were fixed as projects layout copied DLLs to specific sketch based projects and this code was also fixed.
So look here to demo:
Saturday, 23 April 2011
Other thing I want to describe is that in my coding experience Resharper (no marketing intended, yet this software addon is one of the best I've found), had always some odd issues when is working with Visual Studio setup in Spanish (the language of my Windows + Visual Studio setup). This make me reticent every time I've upgraded that I will lose the keyboard mapping and was really odd to setup one by one key combination.
So the tip is the following: go to Herramientas->Opciones->Teclado, set as default: Visual C++ 6 as default shortcut mapping and after this go to Resharper->Options->Visual Studio Integration and apply the Visual Studio style. After this you will be able go use great shortcut integration that Resharper provides.
And let's not forget: Happy Easters for everyone! (for who celebrates it!)
Thursday, 21 April 2011
Pushed the new compiled set of wrappers on SVN and also a 6.5.0 Naro on the bxtrx Mercurial repository.
Next step is to fix Naro starting and investigate if it works correctly with the new wrappers.
Tuesday, 19 April 2011
I've eventually found another way to do it, flicker free as it seem and also the color theme is a bit more vivid.
The reason is that we display a bitmap based background instead a layers based background which OCC (6.3) seemed to have that much problems with.
A problem that might appear after the new wrapper library is generated could be some problems on memory allocation deallocation caused by the fact that now all wrappers have finalizers (a good point will be that memory leaks will be greatly reduced).
Monday, 18 April 2011
Sunday, 17 April 2011
When you will click on it, it will actually check if those relations are possible and it will apply them as constraints.
A video preview can be seen here:
Friday, 15 April 2011
All the new wrappers classes will have finalizers, this might lead to crashes during running.
Thursday, 14 April 2011
- it practically have no high level information (and is really hard to achieve on complex shapes like a combination of results of different tooling). Sketch drawing works with much less shapes. For this reason a second point will likely become true:
- the hinter will be able to introduce constraints automatically for shapes that can take advantage of it. Also the hinter may know some specific interactions to handle them in a proper way. To be more precise: the hinter in the past was simply know that an edge was parallel with the previous two points. The new hinter will likely know that you want a line with another line to be parallel and will do the corresponding work for you. In the global hinter, dragging the radius of a circle will give to you likely erroneous hints like line parallelism, which is at best useless
- hinter will scale better: there will be no shape extraction logic, or a shape that is made of clone to simply pollute the entire scene with edges. If your sketch is unique, all the rest of scene will simply be ignored, so you will notice less clutter and will see it as working faster
So you, the reader, already grasp the ideas and utility of the sketch hinter and when implementation will take shape, I hope you will enjoy working with it!
Wednesday, 13 April 2011
We made a big rewrite on NaroCAD and added: integrated a solver algorithm, implemented the Sketch concept and 2D tools that use the Sketch, reimplemented Extrude to work with sketch shapes, added 2D dragging handles that work on the current sketch. A final updater version was also included in this build.
A sample movie that demonstrates lines drawn having a perpendicular constraint on them. Demonstrates solver behavior when a point is dragged:
Another sample that demonstrates drawing a rectangle (that is built from lines with constraints) and also a circle center connected to one rectangle corner:
Download NaroCAD 1.6.1 Alpha from here.
Tuesday, 12 April 2011
Saturday, 9 April 2011
Friday, 8 April 2011
Thursday, 7 April 2011
Wednesday, 6 April 2011
Sunday, 3 April 2011
SketchSolve have mostly a dynamic programming solution optimizer that will apply the constraints using a big dispatcher to compute the errors that may happen in applying the constraints.
From NaroCAD standpoint challenges are at two levels: sketch shapes need to be sketch oriented, so by design all shapes get references to a sketch. The second problem is how to setup at programming level map the Line, Point, Arc and Circle from NaroCAD to SketchSolve semantics and after the SketchSolve is done, to make things back. Another small feature, yet useful is that those constraints are in a chain, so at programming level, the code at NaroCAD level is smart enough that by simply stating a shape, will build all the dependency chains to be computed in SketchSolve. To be both efficient, this code uses the GraphMapping component that compute back-references and get the mapped constraints.
So let's take a simple(st) case:
"NaroCAD have defined two points and one constraint (PointToPoint) and one point may be moved"
How the back logic works:
- the scene computes the back references: so P1, P2 are references by P2PC
- BFS algorithm will find in P1 -> P2PC -> P2
- a re-mapping will translate NaroCAD shapes and constraints will be converted in SketchSolve logic
- SketchSolve will solve the the constraint system and will retranslate shapes to make the system to work
- at the end shapes will be un-mapped from SketchSolve so the constraints will work accordingly
Thursday, 31 March 2011
In fact this code works with minimal code to include all existing SketchSolve in NaroCAD.
This code is also an internal working feature and we are team are thinking the way things will work integrated eventually at UI level.
This milestone is important as matches the most of refactors of NaroCAD were just in idea of separating the internal logic between sketch shapes to permit SketchSolve to operate.
Wednesday, 30 March 2011
I also implemented a close behavior when double clicking the application button.
Tuesday, 29 March 2011
If you did click on an extrude and was a wrong choice, you will click once again and it will be removed from actual list of extrudes.
Bugs are mostly in flickering area and sometimes auto-facing will not catch all faces. Probably when code will be ported to OpenCascade 6.5 a lot of fixes will appear in this area.
Hopefully this new extrude will save clicks, will be more precise (as you can use both the slider and the values using expressions if needed). so enjoy using it! (after last of bug fixing will make it better)
Monday, 28 March 2011
The sketch will be useful also when integrating the solver, as the solver uses 2D coordinates to find solutions. We'll use the sketch plane to calculate the 2D points from the 3D ones.
Modified the circle tool to work on sketch. It started to work. Some final polishing needed.
There are remaining bugs there but they are going down (mostly in auto-face area)and finishing the dialog that sets extrude.
The code is a bit harder to work with cause can be as many extrudes at once and previously were bugs in how references are stored. Hopefully in short time the extrude will be previewed as a video to express it how it works.
Sunday, 20 March 2011
Some of the changes will be:
- you can extrude more faces at once that are generated just in the moment you select extrude
- there will be a non-intrusive mini-dialog specific for extrude
Work is still ongoing, but I just wanted to post this as things start getting shape.
Friday, 18 March 2011
With this, the Updater is almost completed. The only things that need to be done are to implement the options from the first message box and to test it for any possible bugs.
The updater from the last release has a bigger problem than expected. If you want it to do nightly updates, you have to check both updater check boxes, and delete the "auxiliary' directory from NaroCAD. This problem only appears for nightly updates, but even so, it's not quite what I had expected.
Tuesday, 15 March 2011
The places where this code which fails were around (and now are fixed):
- face picker feedback (a circle that shows the plan you're in)
- some actions will have a skeleton to be fixed that they are dependent (here is about the Arc actions)
- another action (Extrude) have a skeleton that will be developed in future to be smarter, right now the skeleton code is here, but more will follow in another blog post
Sunday, 13 March 2011
Next steps would be to add also parallelism and perpendicular constraints (to cover cases like a rectangle made from lines with constraints) then start integrating into Naro the solver.
Saturday, 12 March 2011
Wednesday, 9 March 2011
This will make really easy from internal logic point of view things like smarter common point dragging will make all shapes related to move, without any "constraint" logic and so on.
Also the code is made fairly simple by making that mostly the changes to go from:
builder.Point3D = Points;
var documentPointLinker = new DocumentPointLinker(_previewDocument);
var firstPointBuilder = documentPointLinker.GetPoint(Points).Node;
builder.Reference = firstPointBuilder;
This will make automatically all "magic" to reference external points.
The external code that uses internal line structure, change minimalistic too, like from: axis.SetLocation(Dependency.TransformedPoint3D.GpPnt);
As user, you will see somelike this:
NaroCAD tries to keep the cadence of a new release at every 3 weeks (and we focus to do development for first three weeks) and we mostly consider a line of releases and at every new release we will add a 0.0.1 to its number.
Anyway, as people we judge version numbers. Windows 7 even is like a new Explorer and a Windows Vista SP2 kernel, we consider Windows 7 as being "vastly superior" to Vista bad reputation.
So we did jump to 1.6 line as we considered that if you did not like the 1.5.0, it worth the upgrade. Doing a bit of cherry picking, you will find that 1.6 will have back the updater, will have a smoother experience all over the place, a faster hinter (both UI wise and how is computed internally), you have gizmos. So if you refrained to use NaroCAD as it was missing this or that feature, was an invitation just to check if it does really gets better.
So in short what should be to learn: we do development incrementally, we try to make all builds stable (yet some specific tools lack on it, we love crash reports, and if we can reproduce we work hard to fix those tools, or rewrite them to be easier to use and to make more sense). Also we do at every around 3 weeks a new release, if you will like to know if you are ready to upgrade, try this blog to get the announcement and to see if new features make you love those tools and if they do, you're more than welcome to update.
At the end, we want to increase the version number to you to know that it worth the upgrade, if you had a 1.5.0 like release, and was something you dislike (who knows, maybe 1.6 it will be the case for you) and as you may see that this development of 1.6.1 will not fully fill your needs (we cannot rewrite all NaroCAD in 3 weeks), you can certainly try 1.7.x and you will likely be more than impressed. We also have an updater that makes it easier to you to be up-to-date so you're encouraged to test releases, and every crash will make for us possible to test and fix your problems.
Tuesday, 8 March 2011
- duplicate code was removed. At the beginning, the version files were added manually in our projects. After the changes, the version files are red from the full.iss files.
- another improvement is a project that automatically generates all the version data ( the version XML file and all compressed files)
The only thing that's missing is a window that tells the user if newer versions are available and the new tools. At the moment, the updater will automatically search for new versions if the appropriate check boxes are checked from the options menu.
- Updater: is much better than previous iterations: it have better consistency checks. You will use much less bandwidth, because it will download just necessary files, even for us, the versioning is made in a much smoother way. We will continue to make the updating experience as smooth as possible.
- Spline interpolated, Control point spline: they will work more precise and smooth than ever: you will see live how they are made, you are able to use command line to set precise coordinates, you can combine and split them with an intuitive way to do it: click on the points that are automatically computed to show to you where you can split those lines, and those splines will be cut accordingly
- Gizmo points are hinter aligned: gizmo will work more precise as hinter will automatically align with various geometry you will have around
- Edge intersection for horizontal, vertical lines: horizontal and vertical lines did not compute previously the intersection points, and right now they do and they do it in a correct way
- Fixed fillet/chamfer 2D: and you can use them in your designs. Another
- Angle between lines: if you have various lines in your scene and you want a precise drawing
- Hinter toolbar: user can enable with just one click point alignment, line continuation and so on. It is much faster and enjoyable to work!
- Redo tool: pressing Tilde key and if you have selected any tool, NaroCAD will switch automatically to the same shape/tool creation context.
- Customizable per action toolbar: so future actions (today Spline and Angle Between Lines are using it) may have specific customization without having a floating (sometimes modal) dialog box making it less intrusive and let you focus on design.
Interested? Download it from here.
Monday, 7 March 2011
I found that causes were mostly for two reasons: was a bug in the way this code was used (by mistake, every time an action was started, was creating a new layer manager), the way it was updated (hinter component of our code may call update view just before adding layer, so nothing visible) and also I think an OCC related bug (that layers seems to not update if no scene (OCC context) changes are made).
So the whole code was moved up and down (in the idea that View component will include the OCC layer manager) so will not make possible cases like previous told. Also those layer structures are cleaned up every time you switch an action (making this code less prone to memory leaks) and will be less prone for API misuse. This refactor make it possible to discover that spline tools show mouse coordinate juxtaposed with hinter text, and this was also fixed.
Friday, 4 March 2011
I've updated the code of Line angle to compute the regular one and give an exception, so you always lose the angle if you will do a Line Set angle, but hopefully I'll find why (or who knows, bxtrx ;) ).
Thursday, 3 March 2011
I changed the versioning file from txt to xml. The advantage is that I have more control over the code because I serialize and deserialize with the help of a special class. This way, it’s enough to deserialize the versioning data once, in order to obtain and easily use all information stored in it. Of course, the older versions with the versioning file as txt won’t work with this one. Even more, the updater code is not completed yet. It is possible that some nightly builds had old updater code. If you have problems starting NaroCAD in the last period, it might be due to unfinished code. If you have such problems, it is best to reinstall NaroCAD. Also be aware that nightly builds might not always work correctly due to unfinished tools.
Wednesday, 2 March 2011
Editing works different for Spline new code as editing tools work by scanning automatically the internal structure of shapes dependency.
Monday, 28 February 2011
A tool to chose the angle between lines (this tool is a bit unpolished, so may change a little in future).
A preview is shown below:
The updater now does a file compression. This means that NaroCAD downloads the compressed files, makes an uncompressing and continues with its job. By downloading compressed files, the download is 3-4 times smaller. One other advantage is that NaroCAD can detect if the file was downloaded correctly by trying to uncompress. If it works, the download was successful. If not, the uncompressing will fail. This way, it’s much easier to determine if a file was downloaded correctly or not. While this change is definitely good for the user, it also benefits us, because it doesn’t take so much time to upload NaroCAD and makes testing the updater a bit faster.
Sunday, 27 February 2011
Interpolated Spline and Control Point spline have two small improvements:
- pressing shift for a point on a spline will delete it. This is useful if you made a point that was defined on a wrong coordinate and you don't want to remake it
- if you start dragging a point, you can insert the coordinate from command line, so you may can work right away and fix it later.
The editing component of spline is not yet finished, but expect more goodies in this area.
See a small demo here:
Also I've did the skeleton work for Split Spline tool but this will be described (most likely) in the next blog post.
Friday, 25 February 2011
Hinter is also shown live how it works as it can be seen here:
Thursday, 24 February 2011
Solver options are exposed from the main interface to be one click away. One other change is that (excluding this screenshot that was a development photo) is changed to be named Hinter. In this way I will not use erroneously interchangeably those two words.
Wednesday, 23 February 2011
So you will have three spline types under NaroCAD and they will work a bit better than in the past.
Some fixes may be still needed but at large Spline related tools are nice to work with and you may enjoy using them (in next releases). OpenCascade 2D layers do not work concomitantly (or I've misunderstood how they work) but I've rewrite to make possible to write multiple texts so when you will use Spline you will see coordinates)
Note: cause of internal changes, if you was using in the past Spline Path tool, I do recommend you to work with nighties, because this functionality is rewritten in a non compatible way. Also the old code was making to add features on it (like a proper editing code) very hard, so will be unlikely to get fixes will be in that area.
So take a look:
Mistake: cubic splines are defined by 4 points.
Yesterday I told you that NaroCAD will only download the files that were changed during the new release. Although I encountered problem with checking the file length, the hash code was a bit tricky. The main problem is that the hash code had different values depending on the time the file was created, and other parameters.
The main problem was that every build changed the hash code of the project files. The only solution to this problem would be to study how the date information is stored in files, study the encryption and decide whether the new file has useful information or not. Still, we mustn’t forget that the size of these files is small (very small if compressed). Even if I were to study these changes, I would still have to download the file in order to do the analysis. Even more, the analysis would be time consuming. The best way is to download all the generated files and check if changes were made to all the other files. This is a bit easier because these files don’t suffer from small changes, usually no changes at all. Given that the files without such problems are more than 70% of all NaroCAD files, the updater will prove much faster than actually downloading and installing NaroCAD.
To tell the truth, even the other files have different hash code when created by the installer. The advantage is that building the projects will not change these files. This means that the developers will not store different hash code for these files when generating the information of the versioning files. If these files are changed, the information from the versioning files will also change. Knowing this helps me to implement a faster updater. The only trick is that the newer hash code of these files (for example OpenCascade libraries, icons, etc) will be compared with the hash code from the current versioning files. This way, the contents of these files will not be red. What does this mean? If someone changes a character of such a file on purpose (so that the length remains the same) the updater will not be able to tell the difference.
So, to make it brief: the files generated by the NaroCAD projects will always be replaced in the new versions, and all other files will be downloaded only if needed.