Romain Behar wrote:
> I've had some issues with making all possible
> pointers as const: there's no const in the geometric
> data structures (mesh.h) and storing const pointers in
> filters isn't possible since k3d::split_edge for
> example doesn't make use of them. In a procedural
> environment, geometry is never modified, just
> duplicated. Would it be worth having const pointers
> wherever possible?
You don't want to make the mesh member data const, as that would prevent
filters from doing their work, even after copying their inputs, e.g. if
you redefined mesh::points_t:
// Points are immutable!
typedef std::vector<const point*> points_t;
Then you can't do anything useful with points:
// Won't compile!
for(points_t::iterator p = m->points.begin(); p != m->points.end(); ++p)
(*p)->position *= scale;
What would make sense is to change the types of all mesh properties from
mesh* to const mesh*, that way you can't make changes to an object's
internal instance of a mesh, but you can modify your own (the same would
apply to bitmap properties).
The reason I haven't done this is that it means storing one type T* in a
k3d::data object, while exposing it in properties as a different type
const T*. k3d::data and its relatives have gotten extremely convoluted,
so I've shied away from increasing the complexity. I do have an
interface-compatible rewrite in mind for post 0.6, to fix this and some
other issues.
Cheers,
Tim

Romain Behar wrote:
> Can k3d::vectorX(const double) go explicit to avoid:
>
> unsigned long wrong_value;
> k3d::vector3 my_vector = wrong_value;
Sounds good to me; I'd actually like to go a step further and eliminate
several of the less useful vectorX ctors including vector3(double),
vector3(double[3]), vector4(vector3&), vector4(vector3&, double) and the
like, but was waiting to get 0.6 out the door. This would be a
reasonable first step to locate any problem areas.
Cheers,
Tim

I've had some issues with making all possible
pointers as const: there's no const in the geometric
data structures (mesh.h) and storing const pointers in
filters isn't possible since k3d::split_edge for
example doesn't make use of them. In a procedural
environment, geometry is never modified, just
duplicated. Would it be worth having const pointers
wherever possible?
Cheers,
Romain
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

Anybody have any suggestions on the best way to generate Python docs?
Given all the progress that's been made recently with the Python engine,
a set of docs is overdue. Things are complicated by the fact that most
of the methods and attributes exposed by our object model are
dynamically-dispatched, so the usual doc strings aren't much help.
Cheers,
Tim

Timothy M. Shead wrote:
> The folowing is my todo list for k3d. The wiki pages isn't keeping up
> with recent progress. I can move this stuff to the wiki later, if Tim
> agrees I should. I would then sort it out with the existing wiki todo,
> and merge all the ideas into one comprehensive, prioritized list.
Yes, I prefer that all of this go into the Wiki, along with any
necessary updates.
Many thanks,
Tim

Timothy M. Shead wrote:
> Joe Crawford wrote:
>
>> So far, in python in k3d, I've only been able to set float values, and
>> boolean on/off attributes. Checkboxes actually.
>>
>> I want to set integer numbers in spinners. I seem to be able to set
>> floats... but not integers. It complains about Long_Check when I try.
>> I tried using
>>
>> object.property = long(number)
>>
>> a practical example would be:
>>
>> object.sds_levels = long(number)
>>
>> But that didn't work. How do you do it?
>
>
> Sounds like a bug, I'll look into it. You are likely the first person
> testing these features ... enjoy the challenge of new discovery ;)
Fixed in CVS.
Enjoy,
Tim

Joe Crawford wrote:
> So far, in python in k3d, I've only been able to set float values, and
> boolean on/off attributes. Checkboxes actually.
>
> I want to set integer numbers in spinners. I seem to be able to set
> floats... but not integers. It complains about Long_Check when I try.
> I tried using
>
> object.property = long(number)
>
> a practical example would be:
>
> object.sds_levels = long(number)
>
> But that didn't work. How do you do it?
Sounds like a bug, I'll look into it. You are likely the first person
testing these features ... enjoy the challenge of new discovery ;)
Cheers,
Tim

So far, in python in k3d, I've only been able to set float values, and
boolean on/off attributes. Checkboxes actually.
I want to set integer numbers in spinners. I seem to be able to set
floats... but not integers. It complains about Long_Check when I try.
I tried using
object.property = long(number)
a practical example would be:
object.sds_levels = long(number)
But that didn't work. How do you do it?
Sincerely,
Joe Crawford
___________________________________
Owner - Joetainment Enterprises
Cell: 604-866-3050
Email: joe@...
Messenger: joetainment@...
ICQ: 103730379
Web: http://www.joetainment.com

I'm forwarding this on behalf of our own Joe Crawford, who is having a
bit of spam blacklisting hell at the moment ...
(By Joe Crawford)
This text is available at: http://joetainment.dnsalias.com:12345/k3d/todo
The folowing is my todo list for k3d. The wiki pages isn't keeping up
with recent progress. I can move this stuff to the wiki later, if Tim
agrees I should. I would then sort it out with the existing wiki todo,
and merge all the ideas into one comprehensive, prioritized list.
The list is ordered. It wouldn't have to be completed in this exact
order, but I made the order based on how badly each feature was
needed, how hard it would be to implement (which since I'm not the
programmer is a ball park estimate), and how important it would be to
the long term viability of k3d. (I also need to merge some of the
stuff from the wiki in here still.)
As a general note, k3d's problem now is a lack of programmers. Many
non-programmers are interested in helping develop other aspects
though. Many suggestions here contribute to taking some of the
development burden off the programmers and moving it to other
developers. The ability to use xml files to setup k3d so far is great.
Some ideas here are to extend that.
I, Joe Crawford am coordinating with several people, on this. I will
soon be assigning one of my employees to k3d development part time. He
has technical skills, but can't work on primary c++ coding.
Many students at Vanarts have also now seen K3d. The helpful
comments/contributions/submissions from them should be very valuable
in the coming months.
As more people see k3d and spread the word, we'll start to get higher
profile. Many people I've showed it to are already quite impressed!
The ability to run it in windows has been a huge, huge, help in this
regard, and will really allow more people to contribute also.
Thanks Tim!
:)
########################################
K3d user interface to do list
########################################
########################################
###############
Tools select unselected
###############
Most of the time, if the user is using a tool other than the select
tool, and he clicks on a unselected object, the object should become
selected and replace the selection.
If the user starts a LMB drag on an unselected object, it should start
a new selection window.
Shift click should add to the selection and Ctrl click should subtract
from the selection.
Shift and ctrl also cause most other tools to act like the selection
too. So even if its close to the manipulator, if the user is holding
ctrl or shift, the selection will be added/subtracted instead of a
move operation started.
###############
Move tool:
###############
Although the current move tool is amazing. It has one major flaw. When
the manipulator is not showing, and you are moving in X only, there is
no way to get back to screen coordinates. I reccommend that if its
constrained to one axis only we make the first mmb click during a move
action go back to screen mode, mmb clicks after that can contrain it
to single axis again.
Rotate and scale should work this way too.
###############
Right click menus:
###############
Where you right click, in the viewport, should not affect what occurs
unless you right click over a very.
Currently, to delete a selected cube, you have to hold the mouse over
it and press delete. Instead, you should only have to select it. Then,
rightclicking anywhere in the viewport should delete it.
###############
Floating Windows:
###############
This is the great bain of GTK applications.
We need a way to make all children windows stay on top of the main window?
Is this possible in GTK?
Another possibility, but far from ideal.... make a hotkey that pops
all children windows into the fg.
###############
Visual Feedback for selection mode:
###############
There's no obvious way to know what selection mode you are in right now.
Object, vertex, edge, face modes in K3d are extremely confusing right now.
Wings has wonderful feedback to know what mode you are in. So does
Blender. (except that their face centers are too big and distracting)
###############
Property label renaming system:
###############
Currently, the names of many properties are terrible from a users
point of view. They seem highly technical, when easier non technical
names exist.
It has been said that the property name should not be changed, since
it would be hell for the developers.
A solution would be to allow xml files to define "labels" for
properties. That way, in the property editor.
The tooltip, hovering the mouse over a property name should say the
real, internal, developer name of the property. Obviously it can
provide more information than that, but that would be an easy way to
make the real names of properties obvious to anyone who wanted to
access them, even if the labels were not the same.
Labels would mean we could alter names without breaking things,
allowing us to change a label name whenever we discovered/decided on a
better label, Joe Crawford, volunteer for the task of defining user
friendly labels for properties.
The label definitions xml file could also have a enabled/disabled
entry, to turn the label translation service on or off.
For internationalization, all label have to be translated eventually
anyway. Its almost like we'd be working to translate programmer speak
into english the first time we do it. A highly highly valuable
translation.
###############
menus/toolbar/context menu relationships:
###############
Eventually, there will be a few ways to access the same functions.
In keeping with established best practices is other applications, The
menubar should contain everything that can be located on a toolbar or
a context menu. (The menubar of course would not have to contain all
properties, or ui elements that are specific to a panel type.)
The tool bar in this way becomes the guaranteed place to find things.
Its also least likely to be used though, because better/faster ways
will exist for things.
xml files already define the toolbars I believe. They can do the same
for right click menus. I think the xml files there should reference
the main menu. That way, someone writing the xml markup for a
toolbar/context menu can see.
This method also guarantees that a hotkey can be set for all toolbar
buttons etc... since the hotkey can really be set for the main menu.
###############
Manipulator Cycle::
###############
Move rotate and scale are cycled between very very often.
Each of the manipulators should have one extra handle/hotspot (or two
right beside each other really). When you're in move mode, you should
see rotate and scale buttons. In rotate mode you should see move and
scale buttons. In rotate mode, move and scale show up. In scale mode,
move and rotate should show up.
###############
Multiple objects in property editor
###############
Assuming selected objects are the same type, the property editor
should be able to edit them together.
###############
Object history in property editor.
###############
This sort of goes along with the above... A major problem right now is
digging for properties. You can't select a light and just change its
intensity. Its intensity won't show in the property editor until you
go into the history and find the lightshader properties. This slowly
down productivity greatly. A solution is easy and obvious.
The properties of each node in somethings history should be stacked in
the property editor. XSI has this killer feature.
It means that if you select a light and a mesh instance, and go to the
properties editor, you'll see both there properties. The mesh instance
shown in the first section (because it was selected last), and the
light properties shown further down.
If you select two lights and a mesh instance... you should only see
one section for the mesh instance and one section for the lights,
(affecting a property in there would affect both lights)
It means that too do something like edit a lights intensity, you don't
have to dig into the light shader. You can just scroll down, and
you'll see the renderman light shaders options.
###############
Middle Mouse Button Scrolling in other windows.
###############
Scrollbars are slow. Any panel that can be scrolled, or panned.
Would we be able to make a new scrollbar frame class in gtk, where mmb
dragging scrolled the contents, whatever they were,(even for text). It
would be like tracking is in the viewports, only much simpler.
The middle mouse wheel is okay for vertical scrolling, but can't
handle horizontal scrolling. MMB dragging works great for scrolling.
Just like the spinners... when mmb scrolling, the mouse should wrap
around the screen when it hits the edges.
That's it!
Sincerely,
Joe Crawford
___________________________________
Owner - Joetainment Enterprises
Cell: 604-866-3050
Email: joe@...
Messenger: joetainment@...
ICQ: 103730379
Web: http://www.joetainment.com

Timothy M. Shead wrote:
> The only exception to this should be Win32 installers, with the
> rationale that there isn't a dedicated distribution organization for
> Win32 - I like to think of it as an orphaned, unsupported platform ;)
And more likely than not, the ordinary Windows user isn't going to
understand downloading source code, compiling and installing.
-- Brett
http://www.chapelperilous.net/
------------------------------------------------------------------------
Practice is the best of all instructors.
-- Publilius

Timothy M. Shead wrote:
> I leave this as an exercise for the community, to coin a phrase. See my
> followup post.
yeah, I really meant "you guys" as in the folks who are doing the Win32
installers... it's kinda pointless for Linux since distros like Debian
and Gentoo (and guys like Thac) already have this stuff packaged and the
installation is relatively automated.
-- Brett
http://www.chapelperilous.net/
------------------------------------------------------------------------
The reason that every major university maintains a department of
mathematics is that it's cheaper than institutionalizing all those people.

I am increasingly of the opinion that we need to get out of the binary
distribution business. This is not to turn our noses up at people who
can't build from source, rather it is about playing to the strengths of
the FOSS community.
Someone who creates a one-off binary has done us a small favor that is
soon obsolete; it doesn't take much additional effort to get a package
into a distribution where it becomes a huge win for everyone - we want
to encourage that.
So from this point forward, I don't think we should accept any binaries
for the SF downloads page. Again, not to discourage people who want to
create binaries, we will continue to link to folks like Thac (who has a
Mandrake package for K-3D 0.5, I just noticed) who are maintaining
up-to-date, quality binaries.
The only exception to this should be Win32 installers, with the
rationale that there isn't a dedicated distribution organization for
Win32 - I like to think of it as an orphaned, unsupported platform ;)
Cheers,
Tim

Brett W. McCoy wrote:
> In addition to the separately installed packages, have you guys
> considered creating a bundle with *both* K-3D and Aqsis getting installed?
I leave this as an exercise for the community, to coin a phrase. See my
followup post.
Cheers,
Tim

Timothy M. Shead wrote:
> I don't know what Win32 installers are out there, so I will offer some
> general guidelines:
>
> 1) The installer must be Free Software
> 2) All else being equal, we should prefer to use whatever Aqsis is
> using. Hopefully this is already what GeekGirl used, and what the
> GTK/gtkmm installers are using.
In addition to the separately installed packages, have you guys
considered creating a bundle with *both* K-3D and Aqsis getting installed?
-- Brett
http://www.chapelperilous.net/
------------------------------------------------------------------------
The UNIX philosophy basically involves giving you enough rope to
hang yourself. And then a couple of feet more, just to be sure.

Joe Crawford wrote:
> Thanks for the help. You were right... it was my distributing of the
> packages that was flawed. On the machine on which I compiled they
> exist. Time to repackage!
>
> Btw, once I repackage, we should get the file on your k3d website!
You should have a look at the installer created by GeekGirl, see
k3d/distribution/K-3D-0.4.2.1-W32-Setup.nsi
I don't know what Win32 installers are out there, so I will offer some
general guidelines:
1) The installer must be Free Software
2) All else being equal, we should prefer to use whatever Aqsis is
using. Hopefully this is already what GeekGirl used, and what the
GTK/gtkmm installers are using.
Cheers,
Tim

Hello,
sorry for late reply, but I couldn't access a Win32
box.
The program is installed in "\Program Files\K-3D\",
if you're using Windows 2000/XP, installed K-3D as
administrator and run it as a user with lower
privileges, you'll get such a message.
Can you confirm?
If your answer is yes, either:
- run K-3D as administrator
- install and use k3d-0.4.2.1-win32.tgz (or .tbz2) as
a user
- or wait for next installer release (no release
date).
Cheers,
Romain
> I installed K3D-W32-Setup.
> An errror massege appears in k3d.bat:
> "ERROR: shadercache path does not exist and could
> not be created".
> How to fix that?
> Thanks.
>
> H.Frik
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

> k3d-renderjob and k3d-renderframe are part of the Win32 build, not sure
> why you wouldn't have them, you might want to look into whatever process
> you're using to distribute binaries.
>
> Once you have all binaries, rendering with the Aqsis Win32 installer has
> been working fine for me, no configuration necessary. To troubleshoot
> problems with rendering, keep an eye on the console, where you will see
> the command-line used by K-3D to run the render engine.
Thanks for the help. You were right... it was my distributing of the
packages that was flawed. On the machine on which I compiled they
exist. Time to repackage!
Btw, once I repackage, we should get the file on your k3d website!
Sincerely,
Joe Crawford
___________________________________
Owner - Joetainment Enterprises
Cell: 604-866-3050
Email: joe@...
Messenger: joetainment@...
ICQ: 103730379
Web: http://www.joetainment.com

Joe Crawford wrote:
> I wanted to render them, and send some screenshots, but noticed that
> aqsis doesn't work on windows. (I did install it.) Is there anyway to
> use k3d-renderjob and such on windows? I noticed I'm missing those
> executables...
k3d-renderjob and k3d-renderframe are part of the Win32 build, not sure
why you wouldn't have them, you might want to look into whatever process
you're using to distribute binaries.
Once you have all binaries, rendering with the Aqsis Win32 installer has
been working fine for me, no configuration necessary. To troubleshoot
problems with rendering, keep an eye on the console, where you will see
the command-line used by K-3D to run the render engine.
Cheers,
Tim

Hey Tim (cc Mailing List, I thought others may be interested)!
I've been showing k3d informally to students at
vanarts...(vanarts.com) I'm going to get them trying it out as beta
testers... (Just those interested). We're using that slightly older
ngui build, because Windows is all we have.
Many features have been quite well received, especially the move tool,
and viewport navigation. I'm going to make a list of student
comments... some might even be interested in joining the mailing list.
You'll be happy to know, we have some excellent Model's as obj format
by Colby Young. (Not the Colby that works in my Studio, but a student
of mine who is quite talented.)
They imported perfectly and look beautiful. They are by far the best
models I have yet seen inside k3d.
I wanted to render them, and send some screenshots, but noticed that
aqsis doesn't work on windows. (I did install it.) Is there anyway to
use k3d-renderjob and such on windows? I noticed I'm missing those
executables...
Thanks.
Sincerely,
Joe Crawford
___________________________________
Owner - Joetainment Enterprises
Cell: 604-866-3050
Email: joe@...
Messenger: joetainment@...
ICQ: 103730379
Web: http://www.joetainment.com

Romain Behar wrote:
> The Debian stable link on the homepage now points to
> the Wiki page!
This seems like such a good idea that I've linked several other
platforms to their respective wiki pages; hopefully we'll see a bit of a
"me too" effect.
Cheers,
Tim