Point size and line width · Issue #1277 · KhronosGroup/glTF

Line width support isn't likely to be fixed in WebGL or OpenGL; it's been deprecated from the desktop OpenGL spec. Skiptocontent {{message}} KhronosGroup / glTF Public Notifications Fork 1k Star 5.8k Code Issues 138 Pullrequests 50 Actions Projects 0 Wiki Security Insights More Code Issues Pullrequests Actions Projects Wiki Security Insights Newissue Haveaquestionaboutthisproject?SignupforafreeGitHubaccounttoopenanissueandcontactitsmaintainersandthecommunity. Pickausername EmailAddress Password SignupforGitHub Byclicking“SignupforGitHub”,youagreetoourtermsofserviceand privacystatement.We’lloccasionallysendyouaccountrelatedemails. AlreadyonGitHub? Signin toyouraccount Jumptobottom Pointsizeandlinewidth #1277 Closed bghgaryopenedthisissue Mar8,2018 ·11comments Closed Pointsizeandlinewidth #1277 bghgaryopenedthisissue Mar8,2018 ·11comments Labels specification Comments Copylink Contributor bghgary commented Mar8,2018 • edited WhenusingprimitivemodePOINTS,LINES,LINE_LOOP,LINE_STRIP,whatistheexpectedpointsizeandlinewidth?Shouldtheybe1? Thetextwasupdatedsuccessfully,buttheseerrorswereencountered: Allreactions bghgary added the specification label Mar8,2018 Copylink Contributor takahirox commented Mar8,2018 • edited Votingfor1because1isinitialvalueofgl.lineWidth(). https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/lineWidth WebGLdoesn'thavegl.pointSize()buttheinitialvalueofglPointSize()inOpenGLisalso1. https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glPointSize.xhtml Iwantpointsizeandlinewidthinthespec.Butregardinglinewidth,itseemschrome(andotherbrowsers?)stillhasno-effectissuesokeepingonly1wouldsoundgooduntilit'ssolved.https://bugs.chromium.org/p/chromium/issues/detail?id=60124. Allreactions Sorry,somethingwentwrong. Copylink Contributor donmccurdy commented Mar9,2018 • edited Whatwouldbetheimplicationsofleavingthisundefined?glTF2.0definesonlyPBRmaterials,andthereisnophysically-basedchoiceforpointandlineprimitives.... Linewidthsupportisn'tlikelytobefixedinWebGLorOpenGL;it'sbeendeprecatedfromthedesktopOpenGLspec.ThelastcommentinthatChromiumbugsumsitupprettywell.Ithink1isthereasonabledefault,butalsowouldn'twanttodiscourageapplicationsfromusingpolygon-basedlinesifthatsuitstheirusecase. EDIT:sortofcomesdowntoaquestionofwhethertheseprimitivesrepresentaGLdrawcall,oramoreabstractrepresentationofapointorline.GivenweremovedGLSLfromcorespecIleantowardthelatter. Allreactions Sorry,somethingwentwrong. Copylink Contributor Author bghgary commented Mar9,2018 • edited Whatwouldbetheimplicationsofleavingthisundefined? I'mnotsure.IfweexpectimplementationstolookthesimilarthenIthinkweshouldputanimplementationnote? Thespeccurrentlysaysthis: Implementationnote:Whenthe'mode'propertyissettoanon-triangulartype(suchasPOINTSorLINES)someadditionalconsiderationsmustbetakenwhileconsideringtheproperrenderingtechnique: ForLINESwithNORMALandTANGENTpropertiescanrenderwithstandardlightingincludingnormalmaps. ForallPOINTSorLINESwithnoTANGENTproperty,renderwithstandardlightingbutignoreanynormalmapsonthematerial. ForPOINTSorLINESwithnoNORMALproperty,don'tcalculatelightingandinsteadoutputtheCOLORvalueforeachpixeldrawn. SoPBRlightingisvalidforpointsandlinesifnormalsandtangentsarespecified. Ithink1isthereasonabledefault moreabstractrepresentationofapointorline Ifbothofthesehappen,whatunitis1? Allreactions Sorry,somethingwentwrong. Copylink Contributor donmccurdy commented Mar10,2018 Ithink1isthereasonabledefault moreabstractrepresentationofapointorline Ifbothofthesehappen,whatunitis1? WebGLapplicationswillnotbeabletoconsistentlyrenderlinesatanywidthbut1px,Idon'tthinkwewanttorequireanyparticularwayofpolygonizinglines.TheideathatlinesrepresentsomethingmoreabstractthanaGLdrawcallwouldleadmetosayweleavepoint/linewidthsundefined,andputthatinKHR_technique_webglinstead(forpointsonly). Allreactions Sorry,somethingwentwrong. Copylink Contributor Author bghgary commented Mar10,2018 • edited I'mconcernedwewillnothaveconsistentimplementationsifweleavethemundefined,butmaybeI'moverthinkingthis. Allreactions Sorry,somethingwentwrong. Copylink Contributor gkv311 commented Mar11,2018 • edited Justacoupleofthoughts. 1pxisactuallynotverynicedefinitionfor"consistent"displaying. IsupposethatnowadaysalldevelopersareawareaboutHiDPI/Retinadisplays(mobile/desktop-nevertheless).1-pixelwidthlinelookstoonarrowon2xscaledisplayand3xscaledisplaymakessuchlineworseevenfurther!Thoughnon-integerscalefactorslike1.5xmakemorefun. Forthisreason,LINEprimitivesbecamealmostuselesswithdeprecationofglLineWidth()inOpenGL... That'sespeciallyfunny,takingintoaccountthatCoreProfileistheonlythingthatactuallydisallowsusingglLineWidth()inmodernapplications-everyGLdeveloperknowsthatalldriversstillimplementsthisfeatureinCompatibilityProfile,andevenallOpenGLESdriversthatIknowsupportlinewidthshigherthan1(savetheAngleproject)!ItisdifficulttounderstandwhyvendorshavenotreturnedthisfeatureatleastinformofGLextension... Allreactions Sorry,somethingwentwrong. Copylink Contributor donmccurdy commented Mar14,2018 Thereisatensionhere—wepreferconsistentimplementations,andwe'vebeencarefultoensureconsistencyforPBRmaterials(whicharebroadlyused). However,theonlyconsistentthingwecouldputintothespecificationherewouldbe1pxlinewidthsandN-px(square)points.Butpractically,1pxlinewidthsandsquare,distance-agnosticpointsarenotlikelytobebroadlyused.WebGLusersareprobablyusingtheseasinputstocustomshaders,orconvertlineprimitivestomesh-basedlines.Cesiumusersprobablywantpointsizebasedondistancefromcamera,etc. So,I'drathernotaddpoint/linesizepropertiestothespecificationjustforthesakeofhavingsomethingtoenforce,ifapplicationsarenotlikelytouseit.ThismightbemoreappropriatefortheWebGLextension. Addingafixed1px-widthrequirementtothespecisOKwithme,butfeelsmoreappropriateasanimplementationnotesothatapplicationsarestill"conformant"iftheychoosetodosomethingmoreappropriate(becausethereisoftensomethingmoreappropriateforagivencontext). Suggested: Implementationnote:ThecoreglTFspecificationdoesnotdefinesizeandstyleofpointorlineprimitivesatthistime.Pointandlinewidthsof1pxinscreenspacearesuggestedforconsistency,butapplicationsmayusevarioustechniquestorendertheseprimitivesasappropriate. 👍 3 bghgary,takahirox,andpjcozzireactedwiththumbsupemoji Allreactions 👍 3reactions Sorry,somethingwentwrong. Copylink Member emackey commented Mar14,2018 @donmccurdySoundsgood.I'llpointoutthatwhileaddingapointsizetothevertexshaderinWebGLdoesproduceasquarepatternoffragmentsintherasterizer,it'suptothefragmentshadertoactuallydecideonalphavaluesanduseofdiscardforeachofthosefragments.Asimpleshadercouldmakethepointsround,ortriangular,oranyothershapethatfitsinthesquareprovided.SinceeachrenderingenginecomesequippedwithitsownPBRshaderforglTFPBRmaterials,presumablyeachenginewouldalsobefreetoincludeitsownshaderforroundpoints,ifdesired. Allreactions Sorry,somethingwentwrong. Copylink Member emackey commented Mar14,2018 • edited Thereservedvariablegl_PointCoordtellsthefragmentshaderwhereyouareinsideamulti-pixelpoint. Cesiumusesithereforroundpoints. TheactualpointsizeinpixelsiscontrolledbythevertexshaderinWebGL,witheachvertexbeingaseparatepointwithitsownscreen-spacesize.Cesiumdoesthathere. Allreactions Sorry,somethingwentwrong. Copylink Member pjcozzi commented Mar15,2018 @donmccurdythere'sthree+1'sabove,perhapsopenthepullrequest? Allreactions Sorry,somethingwentwrong. donmccurdy mentionedthisissue Mar19,2018 Addnon-normativesectionforpoint/linematerials. #1290 Merged Copylink Contributor donmccurdy commented Mar19,2018 Opened#1290. Allreactions Sorry,somethingwentwrong. pjcozzi closedthisascompleted in #1290 Apr8,2018 bghgary mentionedthisissue Nov6,2018 Primitiverestartmodels KhronosGroup/glTF-Asset-Generator#466 Merged Signupforfree tojointhisconversationonGitHub. Alreadyhaveanaccount? Signintocomment Assignees Nooneassigned Labels specification Projects Noneyet Milestone Nomilestone Development Nobranchesorpullrequests 6participants Youcan’tperformthatactionatthistime. Yousignedinwithanothertaborwindow.Reloadtorefreshyoursession. Yousignedoutinanothertaborwindow.Reloadtorefreshyoursession.