Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
ImGui new thread - Page 20 — Gideros Forum

ImGui new thread

11516171820

Comments

  • rrraptorrrraptor Member
    edited August 10
    @hgy29 I faced a strange problem. If you have lots of triangles then gideros cant render them properly...?

    Is it possible to fix it somehow?

    With anti-aliasing (80 nodes, ~1140 triangles each):

    Without (90 nodes, ~500 triangles each):


    In both scenarios I have artifacts even though In a second test I have significantly less triangles
  • there is a limit on the number of triangles in a single mesh. but probably the cause here is something different.
  • rrraptorrrraptor Member
    edited August 10
    keszegh said:

    there is a limit on the number of triangles in a single mesh. but probably the cause here is something different.

    46k triangles, 80 nodes - artifacts
    87k triangles, 80 nodes - artifacts

    Maybe it is the vertices...?
  • hgy29hgy29 Maintainer
    I think there is a limitation in indices size, they used to be 16 bit, so max 64k vertices
  • hgy29 said:

    I think there is a limitation in indices size, they used to be 16 bit, so max 64k vertices

    Found this:
    https://github.com/ocornut/imgui/blob/268565079c56600c197602683391a1bc8afba014/imconfig.h#L94
    So the question is: do we have vertex offset support?
  • hgy29hgy29 Maintainer
    Well actually Gideros does support 32 bit indices, so we could just enable them on ImGui and change the rendering line at imgui_bidnings.cpp:2020:
    //shp->drawElements(ShaderProgram::Triangles, pcmd->ElemCount, ShaderProgram::DUSHORT, idx_buffer + pcmd->IdxOffset, true, NULL);
    shp->drawElements(ShaderProgram::Triangles, pcmd->ElemCount, ShaderProgram::DINT, idx_buffer + pcmd->IdxOffset, true, NULL);
    We could additionnaly support vertex offset at line 1997 and below.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • hgy29 said:

    Well actually Gideros does support 32 bit indices, so we could just enable them on ImGui and change the rendering line at imgui_bidnings.cpp:2020:

    //shp->drawElements(ShaderProgram::Triangles, pcmd->ElemCount, ShaderProgram::DUSHORT, idx_buffer + pcmd->IdxOffset, true, NULL);
    shp->drawElements(ShaderProgram::Triangles, pcmd->ElemCount, ShaderProgram::DINT, idx_buffer + pcmd->IdxOffset, true, NULL);
    We could additionnaly support vertex offset at line 1997 and below.
    Yeah, I realized that :)

    800 nodes:

    Performance is bad, but no artifacts ^^

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • hgy29hgy29 Maintainer
    @rrraptor, I am about to build a new Gideros release, shall I wait for an ImGui update ?
  • hgy29 said:

    @rrraptor, I am about to build a new Gideros release, shall I wait for an ImGui update ?

    Well, there is some small things that I want to add, but nothing special, so you can build :)
  • @rrraptor , this is what i wanted and managed to make thanks to your help:


    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • keszegh said:

    @rrraptor , this is what i wanted and managed to make thanks to your help:


    Nice :wink:

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • keszeghkeszegh Member
    edited August 12
    keszegh said:


    i have the following window variant which snaps to grid points:

    function ImGui:beginWindowSnapped(label,p_open,flags)
      local dragFlag = self:isMouseDragging(KeyCode.MOUSE_LEFT)
     
      if (not dragFlag) and self.snapX[label] then  
        self:setWindowPos(label,self.snapX[label], self.snapY[label]) end
     
        local r1,r2=self:beginWindow(label, p_open, flags )						
     
        if (dragFlag) then 
          local wx, wy = self:getWindowPos()
          self.snapX[label] = ((wx + _GRID_CELL/2 - _GRID_OFFSET_X) // _GRID_CELL) * _GRID_CELL + _GRID_OFFSET_X
          self.snapY[label] = ((wy + _GRID_CELL/2 - _GRID_OFFSET_Y) // _GRID_CELL) * _GRID_CELL + _GRID_OFFSET_Y
        end
        return r1,r2
      end
    @rrraptor , i've realized that this code actually triggers snapping not only when the window is dragged but when any mouse dragging happens. this is a waste of resource (and also sometimes it moves the window when it is partially out of the screen, that's how i noticed the issue. i don't know why yet - EDIT: it's because // is different for negative values). in any case how can i know that a window is dragged (or resized)?
    EDIT: for the resize part there is the callback, so that's fine. only the drag move is a question.
    EDIT: i've noticed that this version also has the issue that if i only drag the window only slightly then it does not set 'isMouseDragging' to positive and therefore the window is not snapped at all. - to correct this i can change the first line to local dragFlag = self:isMouseDown(KeyCode.MOUSE_LEFT) but then it is an even more waste of resources.
  • keszeghkeszegh Member
    edited August 12
  • @keszegh use
    ImGui:getMovingWindow()
    I came up with this:
    ImGui.checkDropEvent = {}
     
    function ImGui:beginWindowSnapped(label,p_open,flags)
    	local id = self:getMovingWindow()
     
    	if id == nil then 
    		if self.checkDropEvent[label] then 
    			self.checkDropEvent[label] = false
    			self:setNextWindowPos(self.snapX[label], self.snapY[label])
    			--print("DROPED")
    		end
     
    		return self:beginWindow(label, p_open, flags )
    	elseif id == label then
    		local r1, r2 = self:beginWindow(label, p_open, flags )
     
    		local wx, wy = self:getWindowPos()
    		self.snapX[label] = ((wx + _GRID_CELL/2 - _GRID_OFFSET_X) // _GRID_CELL) * _GRID_CELL + _GRID_OFFSET_X
    		self.snapY[label] = ((wy + _GRID_CELL/2 - _GRID_OFFSET_Y) // _GRID_CELL) * _GRID_CELL + _GRID_OFFSET_Y
    		self.checkDropEvent[label] = true
    		--print("MOVED")
    		return r1,r2
    	end
     
    	return self:beginWindow(label, p_open, flags)
    end
  • thanks, looks good, i will check.
    actually there should be an event when moving is finished, it still seems to be a waste to compute the snapping point all while moving the window even though only when it is not moved anymore it becomes relevant.
  • keszeghkeszegh Member
    edited August 12
    so at the end this is how i decided to do, seems to be the least number of unnecessary computations, as mousereleased happens rarely:
    function ImGui:beginWindowSnapped(label,p_open,flags)   
      if self:getIO():wantCaptureMouse() and self:isMouseReleased(KeyCode.MOUSE_LEFT) then    
        local r1,r2=self:beginWindow(label, p_open, flags )						
        local wx, wy = self:getWindowPos()
        self.snapX[label] = math.floor((wx + _GRID_CELL/2) / _GRID_CELL) * _GRID_CELL
        self.snapY[label] = math.floor ((wy + _GRID_CELL/2) / _GRID_CELL) * _GRID_CELL              
        return r1,r2  
      else
        if self.snapX[label] then 
           self:setWindowPos(label,self.snapX[label], self.snapY[label]) 
           self.snapX[label]=nil 
        end
        local r1,r2=self:beginWindow(label, p_open, flags )
        return r1,r2
      end  
    end
    optimally i would change
     if self:getIO():wantCaptureMouse() and self:isMouseReleased(KeyCode.MOUSE_LEFT) then
    to
    if self:getIO():wantCaptureMouse() and self:isMouseReleased(KeyCode.MOUSE_LEFT) and self:getMovingWindow()==label then
    but it seems that at the moment when the mouse is released the moving window is already a nil.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • @rrraptor , if you remember those issues with 'triangles in top right of items', it is still wrong in new version. i still need to do this workaround of yours:
        local cx0 = draw_list:getClipRectMin()
        local cx1 = draw_list:getClipRectMax()
        x1 = math.clamp(x1, cx0, cx1)
    and even in this case when a slider appears in my file browser, then parts of the triangle become not visible and so they become smaller.
  • @rrraptor , i want to make color buttons in a palette to be sources for drag'n'drop but they should not be targets for drag'n'drop. how can i do that? thanks
  • keszegh said:

    @rrraptor , if you remember those issues with 'triangles in top right of items', it is still wrong in new version. i still need to do this workaround of yours:

        local cx0 = draw_list:getClipRectMin()
        local cx1 = draw_list:getClipRectMax()
        x1 = math.clamp(x1, cx0, cx1)
    and even in this case when a slider appears in my file browser, then parts of the triangle become not visible and so they become smaller.
    I cant do anything about it.
    keszegh said:

    @rrraptor , i want to make color buttons in a palette to be sources for drag'n'drop but they should not be targets for drag'n'drop. how can i do that? thanks



    ui:colorButton("Button1", color1, 1, 0, 0, ImGui.ColorEditFlags_NoDragDrop)
    ui:separator()
     
    ui:colorButton("Button2", color2, 1, 0, 0, ImGui.ColorEditFlags_NoDragDrop)
     
    if ui:beginDragDropSource() then 
    	ui:setNumDragDropPayload("color", color2)
    	ui:text(("0x%06X"):format(color2))
    	ui:endDragDropSource()
    end
     
    ui:colorButton("Button3", color3, 1, 0, 0, ImGui.ColorEditFlags_NoDragDrop)
     
    if (ui:beginDragDropTarget()) then
    	local payload = ui:acceptDragDropPayload("color")
     
    	if (payload) then
    		local color = payload:getNumData()
     
    		color3 = color
     
    		--color2 = math.random(0xffffff)
    	end
     
    	ui:endDragDropTarget()
    end

    Likes: keszegh

    +1 -1 (+1 / -0 )Share on Facebook
  • in the documentation:
    isHoveringFlag = ImGui:colorButton(string_ID, color [, alpha = 1, ImGui.ColorEditFlags =
    0, w = 0, h = 0])

    here actually the order of the last 3 param is w,h,flags, isn't it?
  • @rrraptor , about the colorbuttons, isn't it possible to send the 'regular colorbutton payload' from such a custom color button, so that i need only to redefine the 'non-target' color buttons and can leave the rest as they are?
    (also the dragndropped thing is a bit different for default color buttons, but i can probably recreate their look).
  • thanks @rrraptor , your dragndrop code helped me make it the way i want.
  • i got the following crash:
    [1355] ../Common/imgui_src/imgui.cpp: mouse_button >= 0 && mouse_button < ImGuiMouseButton_COUNT
    when calling:
    IO:setMouseDown(event.touch.mouseButton, true)
    (where event.touch.mouseButton was what i got by some touch event)
    in a windows exported exe when i used an app called superdisplay to use my android samsung tablet and pen as a display/drawing tablet for the window device.

  • rrraptorrrraptor Member
    edited October 7
    What is the value for event.touch.mouseButton ?
    This is a function that converts gideros button to imgui buttons: https://github.com/MultiPain/Gideros_ImGui/blob/61cc4dc35111fb2f91325c875c1021f1acb1aad7/main.cpp#L726
    So, available values are: 1, 2, 4, 8, 16
  • rrraptorrrraptor Member
    edited October 7
    Or you can use new function (since 1.87):
    -- "down" is a boolean
    IO:addKeyEvent(key, down)
    IO:addKeyAnalogEvent(key, down, number)
    IO:addMousePosEvent(x, y)
     
    IO:addMouseButtonEvent(button, down)
    IO:addMouseWheelEvent(x, y)
    "key" is any ImGui KeyCode (check here)
    "button" is any ImGui mouse button (check here)
  • @rrraptor , sadly the 3 day trial of superdisplay expired and i did not check what was the value. in any case it should not crash even if an unexpected value is received.

    what is the difference between
    IO:setMouseDown(event.touch.mouseButton, true)
    and
    IO:addMouseButtonEvent(event.touch.mouseButton, true)
    ?
  • keszeghkeszegh Member
    edited October 8
    so i've found another very similar app (called easycanvas). there if i touch the screen with my finger on the android tablet (connected as a screen to my windows pc using this app) then it crashes the same way. i added a print just before the crash line and event.touch.mouseButton is equal to 0!

    EDIT: so knowing this i could do a workaround to change the value to 1 whenever it received 0, but it would be great if
    1. gideros would recognize the 'button' correctly
    2. imgui would not crash even if it gets an incorrect button value
  • hgy29hgy29 Maintainer
    keszegh said:

    event.touch.mouseButton is equal to 0
    1. gideros would recognize the 'button' correctly

    On which platform does this happen ? Qt implementation is rather exhaustive, but win32 isn’t.
  • qt. with the strange setup of an android tablet controlling the windows machine via an app like superdisplay/easycanvas.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • keszegh said:

    what is the difference between
    IO:setMouseDown(event.touch.mouseButton, true)
    and
    IO:addMouseButtonEvent(event.touch.mouseButton, true)
    ?

    setMouseDown translates gideros codes to imgui codes and then uses addMouseButtonEvent. You can check it here: https://github.com/MultiPain/Gideros_ImGui/blob/61cc4dc35111fb2f91325c875c1021f1acb1aad7/main.cpp#L9958

    addMouseButtonEvent allows you to add mouse inputs directly to imgui: https://github.com/MultiPain/Gideros_ImGui/blob/61cc4dc35111fb2f91325c875c1021f1acb1aad7/main.cpp#L10114
Sign In or Register to comment.