OpenGL canvas Update

Software
141

Some of the more advanced users forget how to get to the primary nutz and boltz of things. There is a really good discussion of the differences in STEP and WRL files on this forum somewhere. If I remember correctly, and I may not, that a WRL file created from a STEP file will be dimensionally accurate, and prettier then the STEP file.

However, the original 3D WRL files were created with Wings3D (I think) and were not based upon any accurate CAD program dimensions.

Congrats that you are now a 16 day user of KiCad! This is not meant to belittle you in any way shape or form. Most of us have come to KiCad and wondered WTF why are “they” doing it this way? You will find many such threads on the forum from new users.

At the moment you don’t like the negative replies about your suggestion to make the 3D fields a hallucination.

Do you know the individuals that recently worked very hard to create so many of the 3D models? Hint: you might be arguing with them in this post. For them it is not likely a “hallucination” but is probably a way for them to organize their time to make KiCad even more productive for the vast majority of users.

KiCad has always had oddball quirks; and version 5 is not going eliminate all of them.

2 Likes
142

Hello, “Sprig”

Thanks for your reply.
As a (woo hoo!) 16-day KiCad user, more than half that time has been diverted away from useful learning to (as Bob puts it) by being out in the weeds. He had suggested I should get down to building some boards BUT, the fact is this: as a result of the suggestion to just drop (uninstall) v4 (which was running OK for a newbie) and to install the ‘nightly’ v5, my internal pathways to the Libraries were turned into a mess. And as a result, nothing was behaving even remotely as it should’ve. And so I wasn’t able to build anything.

So, if as Eelik says, I am a guinea pig then Squeak Squeak, I need to say something about my experience.

In response to

I thought, Woh! maybe I am really out of line here----the suggestion seemed to be that those who start a Post just sit back and watch/listen to it unfold, so I’m just too involved in this one. So, I did some checks into other posts (n=5, enough to get a sense of things) and the originator of the Post averages 42.4% of the contributions (w/ standard deviation = 12.2%). I have in fact contributed 46 of 140 posts (now 47 of 141…), or 33%, so I am well within the norm… in fact somewhere in the bottom third of the range…

I can readily understand that. It’s a common situation for the “subject matter experts” to be so immersed in their subject area that they have a hard time stepping back and taking the perspective of a newcomer / non-expert, and may not even have the vocabulary to do that. Having written more than a few technical manuals, having been an editor and coauthor of many peer-reviewed publications , that is a concept that I am quite familiar with and it’s the point I’m trying to get across in this Forum.

In regards to the *.step vs *.wrl files, I Get It (and not, “D’oh! I finally get it!”): v5 can make use of both file types. But it has been pretty clearly stated along the way that, while *.wrl is very nice to look at, *.step is the real workhorse of v5 (even though it is visually ‘bland’), and that the ability to make use of *.step files is a big leap forward of v5. [See %% below]

A significant diversion in this Thread has been the mistaken conclusion that I was trying to use *.wrl files that I had created, and that these files I created were incompatible “flavours” of *.wrl. I have only ever created just one *.wrl (exported from Solidworks), and that one behaves just fine, thank you. Another improper conclusion was that I was trying to view v4 projects I had previously created, inside v5.

These problems arose only after “up-versioning” from v4 to v5, and the mess created in the environment variables, paths, AppData\Roaming entries, and so forth.

%% Currently, the fact that the footprints were pre-filled with *.wrl files (not *.step files, which are ONLY associated with v5 and future releases), means that when a *.wrl file is associated BUT NOT DISPLAYING, I am faced with the possibility that this is a reference to a v4 file lurking somewhere on my system (not cleaned out after uninstalling v4)

And this last point brings me back around to my point: I am still struggling with this v5 installation because, at various turns, I cannot be sure that the non-intuitive and/or peculiar behaviour I observe is the result of the current (possibly corrupted) state of my environment variables, paths, AppData\Roaming entries, and so forth…or whether it is some quirk of KiCad resulting from one or another development decision.

For this reason, this Guinea Pig goes Squeak, Squeak to say: Developers, thank you— your efforts have resulted in a truly impressive software product but, please help me, help yourselves and help all those who will upgrade to v5 and all those who will come newly to KiCad at this point in its life. It will be effort well spent.

Having spent 50+ hours now fussing with this v4 to v5 up-versioning and the fallout from it, and the fact that I still have a system that I don’t / can’t assume to be properly set up (paths, environment variables etc), I respect the opinion but don’t feel the criticism of Maui (below) to be on-the-money. It’s not about me. It’s about the wider community of users.

1 Like
143

Simplified: step is for the engineer, wrl for the marketing guy.

More details but still extremely simplified:

STEP: a closed standard for exchanging 3d models between Mechanical CAD programs. It is intended to be loss-less. Meaning if you export step from one MCAD to another.
I can think of two usecases for step:

  • Send data to manufacturing. So it is comparable to gerber in this regard. It allows you to send your model from any cad program without the need that your manufacturer uses the same software. (This can only work if the data format does not loose information)
  • Send data to some other designer using your final product. In this case the part you buy will be part of an assembly drawing. You do not care about adapting the model but you want all relevant things to be there. (Again step being loss less allows that.)

WRL: 3d model exchange format designed for the exchanging pretty models over the web. It stores the model in the form of triangles forming the surface. Such a format can be used by a number of renderers but it is useless for anything to do with mechanical cad.

  • It can not be used in production. If you have a drill hole in step then it will contain information about drill diameter, drill depth, … In wrl there is only an approximation of the resulting surface. There is no way to uniquely get back to the original information.
  • It can not be used for communicating with another MCAD designer as the resulting surface can not be used as a source for so called constrains. (The reason is that the data needed for creating such constrains does not exist in this sort of model.)
1 Like
144

Simplified:

  • KiCAD uses internally WRL to get the best on its internal 3D viewer
  • KiCAD makes the use of STEP libraries to convert its internal 3D representation to a mechanical precise counterpart in STEP

Then, for the user, the experience has been already pushed to the best options available, without the need to even knowing why.

1 Like
145

Not really.

  • you have been told that v5 is not even out there, so there is not even an sketched guide to migrate smoothly from v4 to the not even released v5.
  • you have chosen to go the hard way and now you pay for your decision
    (BTW there are many power users that switched to v5 without complaint)
  • it seems to me you are not listening. This is NOT a dev forum… go to kicad developers list and do your concerns.

Your experience should have let knowing that the library is something that has to be managed by yourself. You should use the KiCAD libraries as a starting point to build your own private library that would not be changed by KiCAD updates… you should read the manual and learn how to use the environment variables to create your working environment. If you had spent few time searching the forum about this, you probably would not be at this point.

Then it is time to “roll up the sleeves and get to the task!”:

  • Being so good in this task, you could do this job for KiCAD community.
  • You may also choose to donate to CERN suggesting for what you would like your donation would be used.
146

One of the changes from 4 to 5 was how the libraries are organised. Libraries are hosted on Github and are downloaded as separate repositories for libraries, footprints and models. The workflow is to fork the repositories, an to add your own models to your fork and then put in a pull request on your fork. It is not an immediately obvious work flow and, even if you are familiar with git, is a little tricky at times. If you add a model to the 3dmodels repository , you would also need to fork the footprints repository and add a pull request for the model reference to be added - i.e. double the pain. The devs have made the (sensible) choice that this can be simplified by defining the name & path of the required 3d model in advance, halving the number of pull requests (which obviously have to be applied at the same time). This does make it easier to add models and your experience with Solidworks would be very welcome as you may be in a position to submit some models yourself.

Nobody’s board ever broke because there wasn’t a nice 3d rendered model, so I understand the rationale and priorities here.

147

Well, for what it’s worth, I think it is. If this hadn’t happened, we wouldn’t be so well aware of the situation. Rene posted the issue in the developers mailing list. I don’t think it would have happened without this thread and the problems which von_Whimhurst faced. And as I said earlier, my overall evaluation of the situation with v4->v5 is that in the current state the installers/packages and KiCad internals KiCad 5 isn’t ready for fluent v4->v5 migration. There’s some documentation coming and now we are better prepared. But sooner or later someone - several people - of the larger user community would have faced these problems. And they will face them unless installers/packages and/or KiCad internals are changed. Documentation is a good thing, very valuable, but the less there’s need for documentation, the better (I don’t believe anyone would argue against that). Personally I would like to see some ready-made creative solutions, like “kicad-5-for-v4-projects” with separated configuration and compatibility libraries which I mentioned some 1000 posts above.

148

Go ahead, there is plenty of room to help in KiCAD… you can have your role in that instead of asking for a better of anything.

149

Did you expect someone to read those manuals? Maybe Kicad documentation writers expected you to read the manual.

We cannot blame developers for the lack of documentation of a version that has not been officially released yet.

I agree in one point: there is the need to document how to manage the libraries. Then, we should explain that the official libraries are a particular case of all the possible libraries.
And we should explain that environment variables are very useful but not mandatory.

Some newbies can see a mess with library management of symbols, footprints and 3D models. I’m a newbie with other programs all the time and I usually read the documentation before asking for help or complaining.

I will go ahead, Maui :wink: I wrote an explanation in the Spanish forum. I think I will rework and translate it into English.

That’s the point!
In my case, I also use the official libraries only as a starting point to build my own ones. And sometimes with different versions of the same footprint for different clients.

Librarians have made a great job reorganising all the stuff for version 5. And they know there will be more job to do for version 6 with eeschema upgrade.
It is a non-apreciated effort for people who want a program working out of the box.

2 Likes
150

Hmmm. You are blaming me for taking the advice of someone (Eelik) who seems to speak as a member of the development team (see quote below). Nobody chimed in and said, NO, YOU FOOL—DON’T DO IT!

Note to Eelk: Don’t take this personally! You offered your advice in good faith and lacking any contrary opinions, I took it.

151

Hmm just having a look at the FAQ?

Moreover, you are saying you have more than 30 years of software use and you need to get someone else suggestion to know which is the risk in using developing releases or making a transition to a new release of the sw?

At the end you are blaming again against other people instead of admitting that this is the result of just your own decision.
Nobody forced you not to spend more time at the forum to get the right information for your user case… and you are the only that know your real user case.

And last but not least, as I already told you, many users have switched to v5-pre without big hassle and without blaming anyone.

152

No, I’m not. I follow the developer’s mailing list, I pull the source code from git and compile it almost on daily basis. I have peeked into the code. I have written some documentation (about the environment variables) and have recently been going through the Getting Started guide, making changes for version 5. I have been an Open Source developer in another project and worked as a programmer. But I’m not a KiCad developer. Not, even though I recently was accidentally granted the developer badge which is visible in the avatar icon of those who are part of the development team.

153

I also want to remind that I said “For a beginner who has no valuable projects yet, now is good time to start with nightly builds.” That’s still my opinion. If a beginner comes now to KiCad, I think there’s no good reason to start with KiCad 4, even when 5 isn’t ready yet. The story is different if someone thinks about changing to 5 from 4 with existing projects.

Actually you were never asked what kind of projects you have and do you want to migrate them to KiCad 5. And then there came this problem with general update from 4 to 5 which wasn’t anticipated as well as it should have been.

154

I switched with big hassle, but I didn’t blame anyone because I took the risk and I was the one who was to blame. But things are a bit different now. Considering that KiCad 5 could have even already been released if there wouldn’t have been critical bugs for some weeks, I feel uncomfortable about the fact that such a big problem (the non-compatible fp-lib-tables) was uncovered this late. I just don’t feel it’s fair to blame a newcomer if he doesn’t read all the possible documentation. Such a updating process really should be so much automated that a user didn’t have need to read documentation about it to be able to use the new version with the new libraries.

155

as in my prrevious reply:

156

Yes, of course, but the problem was that, at least right now, when KiCad pre-v5 is installed and it replaces v4, the new footprint libraries are installed, but the global fp-lib-table isn’t updated and there’s not even a warning about it. This may be fixed somehow, considering the developer discussion which is going on, but it’s not a simple or rare issue. It affects everyone who updates KiCad from 4 to 5. Whether they are using the official libraries as starting point or not.

157

Thanks, Eelik. And thank you for clarifying your status as “not a developer”.

Of course, I agree: newcomers should not be expected to know the entire history of the Forum(s) of KiCad or any other software (which is something I stated previously)

And for the record, although Maui seems to be interpreting that I am “blaming” others, I am not blaming, although perhaps Maui is feels that it’s blame. What I am doing is putting my usage / choices / steps or history, in context.

Eelik is spot-on when he says “really should be so much automated that …”; Again, in my opinion also it is very reasonable to expect a “new” installation to perform all basic functions from the starting gate. That includes Beta versions or ‘nightlies’. A “new installation” should, in my opinion include the situation of performing an Uninstall of one version, and the installation of a new version (i.e., the user shouldn’t have to nuke-and-pave to get a virgin platform on which to build the installation).

Insofar as the sometimes repeated remarks about ‘nobody really needs a 3d version of the board’, well, I guess those who have made such comments have never tried to fit long, skinny boards into tubular pressure housings of geophysical instruments getting plunged several km into a borehole— a task where the overall board layout is often dictated by the component packages, not by the desire to have a simple 1 or 2 layers board and efficient routing. In other words, taller components often have to be placed along the centerline just to make them fit, and the board may have to be >2 layers (with blind vias) just to get the necessary level of routing options.

158

I have my own libraries and templates; I update the fp-lib-table when I need to add or remove libraries to my personal db…
I updates my libraries when I need to add or change my symbols or footprints… No big issue if the format of the libraries doesn’t change… (that is the only risky part to be aware of)
I don’t see many issue if you know how the sw is working and what to do with it…
And just to remember you, v5 is not even released… after the release there will be a transition period in which all (most of) these glitches will be fixed because many users will spot those … that happened in the past from kicad v3 to v4 and it will happen again from v5 to v6 …

159

Yes, but it’s better to catch them before the release. And a couple of glitches have been caught here. I don’t see any reason to blame the original poster. He(?) may have made some mistakes in communication, but communication goes in two directions, and even in this discussion there are more than one party who are guilty of imperfect communication… Me included.

160

That should be “Myself included.”

:wink: :smiley: :stuck_out_tongue:

1 Like