OpenGL canvas Update


#121

It also doesn’t help that the AppData folder is normally a “hidden” folder that MS doesn’t think that the normal user should need to have to access. (Default Windows settings hides all hidden folders.) So any readme files or warning requesters should mention how to show hidden folders in Windows.


#122

Rene:
Hi, I was just reading through the thread again.

In clear response to the the quoted passage: No, I don’t expect that every Footprint would have a 3d model to represent it.

But, for someone who’s just did the up-versioning from v4 to v5, and having experienced the problems now partially documented in this thread, there’s no wonder that I am left scratching my head when I see a 3d model associated with the Footprint, but no 3d image appears in the 3d viewer.

As we’ve already discussed, KiCad isn’t currently generating error / warning messages when a 3d image, explicitly associated via the Footprint Properties, is not found.

Lacking an error message for this eventuality, it is very difficult (time consuming and frustrating, too) for a newcomer to KiCad to sort out what went wrong, and where it went wrong.

The quote I added above seems to suggest that the Library currently being distributed (with v5 / nightlies) was never purged of file associations to 3d image files no longer existing in the current distribution of packages3d. I can appreciate that, to examine every footprint manually would be a monumental task and nobody in the development team has time for that sort of tedium. But, would it not be possible to automate the process of comparing the footprint associated 3d shapes, and check them against the current distribution’s library of shape-files?


#123

just a tip for you guys, in Windows you can access the “Roaming” folder by running %APPDATA% (start->run) even if the folder is hidden.


#124

I suggest you reread the above quote again. It’s not that anything wasn’t “purged”, the 3D model assignment of the footprints have intentionally been “pre filled” as place holders for models which don’t yet exist. Create the model if you are missing it, give the model the name that has already been assigned in the footprint, and move on. But this being the case I agree there should definitely not be any error messages displayed for missing models.


#125

Here i disagree. There should however not be a separate message for every missing model. A single message containing a list of missing models however would help.


#126

If anything perhaps a single message indicating there are missing 3D models. But this will encourage people to then remove the assigned model names from the footprints in which case there isn’t much point to pre filling them in the first place.


#127

Or people get motivated to contribute the missing models to the official lib. Who knows what such a message would bring. Failing silently is just not my idea of how it should be done. (Maybe a tickmark for turning of the message for either the current session, project or globally might be a good idea.)


#128

it was already like that… only on first 3D rendering the message would have appeared… until 3D viewer is closed no new messages, also if you change your board. I’m not sure it is gone now on v5.


#129

I get no error message at all in todays nightly.


#130

I understand your point of you completely. If the message only appeared once per session that might not be too bad. Or what about a “3DC” button similar to ERC/DRC that checks your board for any 3D errors and gives a report? Being able to save/print the report would probably be more useful than just a message that pops up once.


#131

you are right… it is gone… they should have removed recently though…


#132

Hmm.
I can understand that having a consistent pattern for the model’s file-names would be desirable.
But, pre-filling these associations with that name is just (to my mind) too weird: by explicitly making the association, it suggests that the files do in fact exist.

This fantasy association with a non-existent file is digital equivalent of having a hallucination.

IFF your intention is (as it appears to be…) to suggest the file name and path for a future creation, May I suggest that you give these “placeholder” file-names a bogus file-type extension?

Besides and in particular, every one of these “placeholder” files seems to have the *.wrl extension whereas it seems from the discussions that *.step is the preferred method going forward in v5 and that *.wrl files are just eye-candy for the final “glossy” sales pitch. So why *.wrl was chosen as the extension for pre-filling is certainly not obvious (and is in itself confusing, because all of the OLD shape files were *.wrl)

So, for every one of these pre-filled, non-existent files, how about using the file-name extension *.hal [=hallucination], which can be detected by the software to set a specific Warning flag for the user? If and when somebody gets motivated to do so, they can then use the file-name and append the extension *.wrl or *.step to the file they submit to the Git library.


#133

Either or both may exist in the library. If you want to use one other than that specified in the footprint you can change it. Personally I think this should be more easily accomplished, perhaps through a CvPCB like interface.

That was nearly 90 posts ago and you are still going on about it.


#134

It seems to me:

  1. you miss to read at the forum what path produced this library organization.
  2. you do make many time the same request, without searching at the forum if this already exists.
  3. your experience would be much easier if you would comply the previous two points.
  4. you always forget this is an user forum… if you want to be listen for changes go to dev mailing list.

#135

Or in the case of requests for changes regarding the lib head over to github. But to be honest i will not change my opinion based on where a request was made.


#136

+1 … I agree so much… what we have now it is absolutely NOT an hallucination :smiley:
and it took a lot of work from volunteering and skilled people.
I would like to see those people complain with commercial packages :wink:


#137

Really the only downside is that those of us, experienced users who are used to the oddball locations of some things, will now have to take a step back and look where it should have been in the first place.


#138

Most things are quite well documented in json format. So in theory you could even write a program that finds the new equivalent symbol/footprint for old projects. (One major exception are the connector footprints as they do not have specialized symbols and are script generated so there was no need to add their changes to the json file.)


#139

Hello to all:

Reading through the last several posts, it seems like many persons are taking my comment as to the hallucinatory nature of those “pre-filled” files as a personal affront. It’s certainly not intended that way.

Here’s my perspective, and it is in line with what Sprig said (see quote above):

  1. KiCad is in my opinion currently very sophisticated and for this all the volunteer developers deserve kudos
  2. This Forum is for Users.
  3. That there was a separate developer’s forum isn’t obvious because there is a lot of discussion in this Forum (apparently from those who are on the Dev team) justifying why this-or-that was done one way or another.
  4. As a newcomer to KiCad, I think I have valuable insight into how the KiCad program manifests itself to the newcomer, and to the “grass roots” user.
  5. Those who are newcomers should not be expected to dredge through years of discussions in a Forum setting in order to get started (whether it’s commercial software, or shared)
  6. Learning and holding in memory the years of version and development history behind why this-or-that-thing is the way that it is, and why it might not be perfect, isn’t in the best interest of grass-roots users: we’re not members of the diplomatic corps, and I don’t think that any of us want to take up arms in a blood feud.
  7. I think that, whenever changes are made (particularly to a large package of interconnected sub-packages), all developers should be asking, “When someone unfamiliar with KiCad comes to this juncture [menu, dialog, etc], is this [entity, process, etc] going to be intuitive? Or, will it require insider knowledge?” Because, if it does require " insider knowledge, it’s going to generate more Forum discussions and headaches than is necessary.

That wasn’t my intention, to “still go on about it”. But I have said it, I feel am not being heard, and it still doesn’t make any sense to me why anyone would’ve thought that “pre-filling” a file association with a path to a non-existent file would be INTUITIVE to anyone who is a newcomer. Particularly, as it’s been made very clear that the ability to use *.step files in v5 is a significant new feature; preference would be (first) for *.step files in the new library and that *.wrl files are an extra-added-bonus-feature. The choice to “pre-fill” with *.wrl files is not internally consistent with that development arc. In 30+ years of software use, I have never seen such a practice; “explaining” that “prefilling” it in a Forum discussion with reference to history, and/or to design-intent for future use is NOT (in my opinion of course) the same as solving the problem that it creates.


#140
  1. it has been told you many times that all the 3D library has both WRL and STEP models
  2. it has been told you many times that WRL is the default 3D association because it offers better rendering in 3D viewer
  3. it has been tod you that you don’t have to care about changing the WRL to STEP inside a footprint or a board because the internal KiCAD STEP exporter already does it auto-magically (as it has been done for more then 3 years by StepUp in advance also for kicad v4)
  4. it has been told you that all the footprints have already filled the 3D model name and path inside because it is useful… may be it was not clear to you why, but this is to avoid the need to create a new Pull Request to the footprint repository when someone will add (make a PR) a new 3D model to the 3D packages repository.
  5. anybody except you seems to know that there is a kicad developer mailing list where you can reach the devs…

you miss your part in the learning process… you get a good free product, with a responsive and helping forum, but you don’t want to spend time to learn how to improve your skills in learning how to use it with profit and just complain on what others have to do for making your experience more comfortable.

that is sounding amusing, considering this is a thread of 139 posts, most on replying to you… :smiley: