220 19173 article Path: news.gmane.org!not-for-mail From: Christopher Horvath Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Point class Date: Wed, 22 Jul 2015 10:49:09 -0700 Lines: 203 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113fd0424e9de2051b7a6357 X-Trace: ger.gmane.org 1437592765 19774 80.91.229.3 (22 Jul 2015 19:19:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jul 2015 19:19:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC2YFPWU5AOBBOWZX6WQKGQEF5RWUZY@isocpp.org Wed Jul 22 21:19:25 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f72.google.com ([209.85.192.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZHzY4-0000UO-LR for gclcip-std-proposals@m.gmane.org; Wed, 22 Jul 2015 21:19:24 +0200 Original-Received: by qgeu79 with SMTP id u79sf239868520qge.1 for ; Wed, 22 Jul 2015 12:19:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=dEjFhXvUrbTlc+BQAm71Yd2oJLwrUdf+0V3vEiTqHao=; b=E+bB46pe9fJ2Frpy8WbEvnYrMUmI2H9ac8GHAxbglUZs/Gk4c8Uc9r3YxF5jkhx1n/ ZbR0DREEJCBWyx1TahcX43RehBU7P+azIhpMtNOWP7/VcBSQRedZYyV6Ex0vd38Hni52 O6HJE11Y+uuddcnsX+eeW2ocj6sBAXA5F0/xX9eBWUGa/T5BZs4vmghJoa9bPkmd5DgT H6qzQ7L59boLCeh5rTcfJYqjILR9WBTVw6R8ZGl1Pzy/LMIRjUE2gXehtE2NsqKT1gop RdlEN8w994lj/oVZY7pgRJ+g7OZMqb8KWFA4RFUrREWkcWNCDoaoWOPSrUUW9xCItssl uhzQ== X-Gm-Message-State: ALoCoQnYy1V+IxW2PhvWK+qu9UG9AUYaLfPeNc++XboY0GCIUy5xkYbk8zo7EVMD9mrYZYf4DPN8 X-Received: by 10.129.83.136 with SMTP id h130mr4190185ywb.23.1437592763747; Wed, 22 Jul 2015 12:19:23 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.31.210 with SMTP id f201ls395929iof.72.gmail; Wed, 22 Jul 2015 12:19:22 -0700 (PDT) X-Received: by 10.50.41.67 with SMTP id d3mr37335225igl.57.1437592762088; Wed, 22 Jul 2015 12:19:22 -0700 (PDT) Original-Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com. [2607:f8b0:4001:c03::231]) by mx.google.com with ESMTPS id i81si2376406ioe.12.2015.07.22.12.19.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2015 12:19:22 -0700 (PDT) Received-SPF: pass (google.com: domain of blackencino@gmail.com designates 2607:f8b0:4001:c03::231 as permitted sender) client-ip=2607:f8b0:4001:c03::231; Original-Received: by iecri3 with SMTP id ri3so79901123iec.2 for ; Wed, 22 Jul 2015 12:19:22 -0700 (PDT) X-Received: by 10.107.27.195 with SMTP id b186mr6427134iob.140.1437587349607; Wed, 22 Jul 2015 10:49:09 -0700 (PDT) Original-Received: by 10.36.82.13 with HTTP; Wed, 22 Jul 2015 10:49:09 -0700 (PDT) In-Reply-To: X-Original-Sender: blackencino@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of blackencino@gmail.com designates 2607:f8b0:4001:c03::231 as permitted sender) smtp.mail=blackencino@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:19173 Archived-At: --001a113fd0424e9de2051b7a6357 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is a very difficult design problem, because there's a question of semantics and transformations. A point is transformed differently by a matrix than a vector (the difference between points), and each of these are transformed differently than a normal. In the Renderman Shading Language, these correspond to three different functions, "transform", "vtransform", and "ntransform". Some C++ geometry libraries have made strong type distinctions - differentiating "point3" from "vector3" from "normal3", and so on, allowing them to overload the arithmetic operators. Having used several such libraries, they're generally frustrating to use because the data is usually stored simply as "float3" or "double3" or "half3", and the constant static_cast or reinterpret_casting, or worse, new object creation, is tedious. A library I've been using recently, built on top of Eigen and a separate math library as an alternative, doesn't overload arthmetic operators at all, but instead uses explicit free functions for readability - so you can say, transform_point(float4x4, float3), transform_vector(float4x4, float3), etc. This also makes it easy to templatize the arguments to these free functions to any type which meets the minimum requirements. Many users of such an approach, however, find the lack of arithmetic operator overloads deeply annoying. Yet another library I've had to work with recently simply disallows transforming a float3 by a mat44, requiring the user to convert the float3 into a homogenous point as a float4. Then, transform_point becomes operator*(mat44, float4{float3, 1}), and transform_vector becomes operator*(mat44, float4{float3, 0}), and transform_normal becomes operator*(inverse(transpose(mat44)), float4{float3, 0}). This is tedious in its own way. Eigen goes to great (and sometimes frustrating) extents to create odd intermediate types that allow for compile-time removal of unnecessary temporaries. For example, if a matrix is orthonormal, then the operation inverse(transpose(matrix)) is a no-op, and this can be detected at compile time using a traits object on things like rigid transformations. This is useful with very large dimensions, but has difficulties that the intermediate types sometimes produce unexpected results when using "auto". I would imagine a standardization attempt at such a library would be deeply contentious, but probably valuable if consensus could be reached. I hope that members of the graphics and games communities would be involved. Chris On Wed, Jul 22, 2015 at 10:29 AM, Matthew Woehlke wrote: > On 2015-07-22 13:19, David Haim wrote: > > 2) After digging a bit in the Eigen library, I couldn't find an explici= t > > Point class, are you sure they have implemented such class? > > Yes and no; see the vector class(es). There's not much=C2=B9 benefit to > defining a point class vs. a vector class, and a general vector has more > uses. A "point" is just a vector offset from the origin, which is merely > a semantic distinction; it's fairly common to treat "points" as a > semantic subset of "vectors". > > (=C2=B9 Actually, offhand I can't think of *any* benefit except maybe typ= e > distinction, and strong typedefs would make that moot. I feel like > *maybe* there is some benefit, but I can't think what.) > > -- > Matthew > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. > --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --001a113fd0424e9de2051b7a6357 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a very difficult design problem, because there'= ;s a question of semantics and transformations.

A point = is transformed differently by a matrix than a vector (the difference betwee= n points), and each of these are transformed differently than a normal.=C2= =A0 In the Renderman Shading Language, these correspond to three different = functions, "transform", "vtransform", and "ntransf= orm".

Some C++ geometry libraries have made s= trong type distinctions - differentiating "point3" from "vec= tor3" from "normal3", and so on, allowing them to overload t= he arithmetic operators.=C2=A0 Having used several such libraries, they'= ;re generally frustrating to use because the data is usually stored simply = as "float3" or "double3" or "half3", and the = constant static_cast or reinterpret_casting, or worse, new object creation,= is tedious. =C2=A0

A library I've been using = recently, built on top of Eigen and a separate math library as an alternati= ve, doesn't overload arthmetic operators at all, but instead uses expli= cit free functions for readability - so you can say, transform_point(float4= x4, float3), transform_vector(float4x4, float3), etc.=C2=A0 This also makes= it easy to templatize the arguments to these free functions to any type wh= ich meets the minimum requirements.=C2=A0 Many users of such an approach, h= owever, find the lack of arithmetic operator overloads deeply annoying.

Yet another library I've had to work with recentl= y simply disallows transforming a float3 by a mat44, requiring the user to = convert the float3 into a homogenous point as a float4.=C2=A0 Then, transfo= rm_point becomes operator*(mat44, float4{float3, 1}), and transform_vector = becomes operator*(mat44, float4{float3, 0}), and transform_normal becomes o= perator*(inverse(transpose(mat44)), float4{float3, 0}).=C2=A0 This is tedio= us in its own way.

Eigen goes to great (and someti= mes frustrating) extents to create odd intermediate types that allow for co= mpile-time removal of unnecessary temporaries.=C2=A0 For example, if a matr= ix is orthonormal, then the operation inverse(transpose(matrix)) is a no-op= , and this can be detected at compile time using a traits object on things = like rigid transformations.=C2=A0 This is useful with very large dimensions= , but has difficulties that the intermediate types sometimes produce unexpe= cted results when using "auto".

I would = imagine a standardization attempt at such a library would be deeply content= ious, but probably valuable if consensus could be reached.=C2=A0 I hope tha= t members of the graphics and games communities would be involved.

Chris


=

On Wed, Jul 22, 2= 015 at 10:29 AM, Matthew Woehlke <mwoehlke.floss@gmail.com><= /span> wrote:
On 2015-07= -22 13:19, David Haim wrote:
> 2) After digging a bit in the Eigen library, I couldn't find an ex= plicit
> Point class, are you sure they have implemented such class?

Yes and no; see the vector class(es). There's not much=C2=B9 ben= efit to
defining a point class vs. a vector class, and a general vector has more uses. A "point" is just a vector offset from the origin, which is= merely
a semantic distinction; it's fairly common to treat "points" = as a
semantic subset of "vectors".

(=C2=B9 Actually, offhand I can't think of *any* benefit except maybe t= ype
distinction, and strong typedefs would make that moot. I feel like
*maybe* there is some benefit, but I can't think what.)

--
Matthew

--

---
You received this message because you are subscribed to th= e Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, se= nd an email to st= d-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.c= om/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--001a113fd0424e9de2051b7a6357-- .